Deploying The WebPart By Using Features

This time we're talking about how to deploy web parts as a feature. Now, deploying custom web parts the manual way is a bit of a pain - the following things are required for the web part to be used:-

• the assembly containing the compiled web part class to be in the GAC (or site bin with appropriate CAS policy)
• a SafeControls entry in the site web.config to tell SharePoint this control is administrator-approved
• the .webpart (or .dwp) file which contains the web part definition (configuration) to be uploaded to the site's web part gallery

Assuming the user has appropriate permissions, the web part can then be added to a WebPartZone on a web part page. The first thing to say is that there are 2 ways of automating this process:-

• use VSeWSS to create a feature to deploy the web part - simply hit F5 to deploy to your local server; this also generates a SharePoint solution package (.wsp) which can be deployed to other environments.
• create a feature 'manually' by creating the files (e.g. feature.xml, elements file etc.) by hand

Both methods will take care of the 3 steps listed above, so that the files are copied and the SafeControls entry is added. I can't emphasise enough how simple VseWSS makes this process. Additionally, VSeWSS apparently allows simple debugging when F5 is hit, but I had to copy the .pdb file to the hidden folders in the GAC hierarchy to enable this. See my article on how to debug feature receivers for more information.

However, use of VSeWSS typically means there is slightly less control over the deployment options, since the tool writes the files for you and not all of the options are exposed for you to modify (I go into more detail on this in Creating lists with VSeWSS). As an example, VSeWSS will deploy web part assemblies to the GAC (with full trust), but some SharePoint admins prefer assemblies to run from private bin folders instead to isolate any harm they might do. Hence, there are some occasions where you might want to use the second option and create the feature yourself. The remainder of this article illustrates this process, using the example of a web part which should be deployed to a bin folder.

Once the webpart has been developed, we need to create the manifest file, specifying the feature details, assembly, SafeControls entry, and webpart definition file (.webpart):-


Then, we need the feature.xml file which points to the elements file and tells the framework there is another file to process (that being the .webpart file):-



The elements.xml file should look something like:-



Finally, a .webpart file should be generated to define the metadata and default property values of the webpart.

I place this in a folder underneath my feature files alongside the .dll file containing the compiled assembly.

Assuming all the files are in the right place, the solution file (.wsp) can be built using makecab.exe. This solution can now be deployed, thus taking care of the manual steps for webpart deployment. Once this process is familiar (and you have existing files to copy for the next time) this process is quite straightforward.

[UPDATE 22 November 2007 : for bin deployments, the .dll should be at the root of the .wsp file - if it is in a subfolder, it will be deployed to a subfolder of the bin directory which we do not want. See this article's comments for more details.]

Note the DeploymentTarget="WebApplication" instruction in the manifest.xml file. This ensures the assembly is deployed to the application bin folder rather than the GAC. Now, most web parts will require additional CAS policy to obtain the permissions to execute - your assembly will now have the default trust level of WSS_Minimal, so any file io, database or web service access will probably fail. I hope to cover the entries for this in a future article.

So the webpart should now be in the Web Part Gallery and ready to be added to a page.

One thing I also want to discuss is the different ways of adding a webpart to a page. These are:-

• adding the webpart to a WebPartZone (possible in a feature by use of AllUsersWebPart element)
• adding the webpart to the HTML markup of a page layout by dragging from SPD

The main thing to note is that if you want to be able to update webpart configuration as part of updating the page layout itself, the webpart should not be in a WebPartZone. If so, the webpart properties are stored in webpart storage, and updating a page layout (either via a feature or manually uploading to the Master Page Gallery) will not change any web part properties. However, note that web part properties can only be edited by a user if the part is in a WebPartZone. This confused me for a while, and is an important facet of the webpart architecture to be aware of.

Refer From :

http://www.sharepointnutsandbolts.com/2007/05/deploying-web-parts-as-feature.html

Comments:

Hello,

I deploy my web part in almost exactly the same fashion as described here. One problem I can't get around, though, is that the web part dll:s do not get deployed directly to the BIN folder in the web application, but rather in their respective folder, in the BIN folder. In other words, using your exact example, my DLL would end up in bin\COB.Demo.WebPartDeployment.WriteToFileWebPart\ rather than in just \bin. Do you know how to get around this?

Answer:

I don't remember seeing this behaviour when I wrote the article, but I just did some testing and you're absolutely right.

It seems the Assembly element in the manifest.xml file does not like the Location being set to a child folder for bin deployments. The solution is to amend the .ddf file so you have a different structure in the solution package (.wsp). If you keep the assembly at the root of the cab file (and amend the Assembly/Location attribute in manifest.xml accordingly), the assembly will be properly deployed to the root of the bin folder, not a subfolder. All other files can stay in the child folder within the .wsp, it's only the assembly which needs to be moved to the root.

I guess the reason why this hasn't been a problem for me is because we're happy to deploy web part assemblies to the GAC in our environment.

Apologies for the inaccuracy.