his isn’t the article that I set out to write. While researching another article (coming soon) I soon realized there just isn’t a lot of good material on how to troubleshoot Web part deployment, or even precisely how Web part deployment via STSADM even works. This article is designed to explain the moving parts of the deployment process and describe what can go wrong. Hopefully, it will help a few people get their implementations up and running more smoothly.

Why Deploy with STSADM?
Before getting too deeply involved in fixing STSADM Web part deployments, it’s important to understand what STSADM is and why it’s a good platform for troubleshooting Web part deployment.

STSADM is a ‘utility knife’ type of tool that ships as a part of Windows SharePoint Services. It does a wide range of things from site creation to Web part pack installation. If you have SharePoint Services, you already have this utility; it is typically found in C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions60Bin.

Alternative tools such as WPPackager just add additional complexity to the process by wrapping the installation in a Windows Installer file. Worse, these tools don’t really gain you anything. At their core they’re still using the same installation process by running STSADM or calling the Windows SharePoint Services object model calls that roughly equate to the STSADM options.

But whether you choose to download one of these tools or stick with the somewhat plain but very functional STSADM, learning how STSADM deploys Web parts is very valuable.

Understanding the CAB File
In order to troubleshoot Web parts and deployment you must first understand how the process works. This means understanding what STSADM does to the CAB files that you create for it. The CAB files that STSADM wants are not special other than the fact that they contain a manifest.xml file which contains the instructions that STSADM needs to set up the Web part.

There are two basic sections to the manifest.xml file (see Figure 1). The first, which falls under the tag, contains the DLLs, supporting files, and configuration entries that are made by STSADM. The second section, DWP Files, falls under the tag and contains all of the DWP files for the package. DWP files are what the user sees when adding a Web part to the site. They contain the title to display, the description for the hover text, the assembly to load and what the properties are that should be loaded into the Web part. They are the configuration part of a Web part, whereas the assembly is the code that is running.

Figure 1. Get in the CAB: The contents of the CAB file are shown.

In the tag there is a set of tags. Each tag in the set has a FileName attribute that defines the name of the assembly being described. This file should be packaged inside the CAB file.

If the assembly contains the Web parts then it should have a tag (note plural), which encloses one or more tags (note singular), each of which has an attribute for Namespace and TypeName. The Namespace is the namespace that the type belongs in and the TypeName is the specific name of the type in the namespace to make safe (or a * to indicate that all types in the specified Namespace are good). These tags are used to create the appropriate entries in the web.config file. The web.config file entries are nearly identical except they reference the full name of the assembly.

The tag may also contain a tag (note plural), which itself encloses one or more tags (note singular). The tag has an attribute, FileName, which specifies the name of the file to include as a resource. These files should also be included in the CAB file. Class resources are things like images and JavaScript include files, which the Web part will need to operate correctly.

Assembly tags do not need any sections inside of them. If the tag doesn’t have any references inside of it, the assembly is copied just like the other DLLs. This is important when you are referencing other DLLs from your Web part DLL. By adding a separate assembly tag for them you can ensure they get copied during installation so that your DLL can use the referenced DLLs during run time.

The next major section is the DWP Files section. The tag has one or more tags in it. Each of the tags has an attribute, FileName, which contains the name of the DWP file to install. DWP files themselves are XML files as well. They contain a