RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


ASP.NET 2.0 Web Part Infrastructure and SharePoint 2007 : Page 5

Find out how to make your Web Parts communicate with each other and share data.

Deploying Your Web Parts in SharePoint 2007
I am going to install these Web Parts on a local MOSS installation that I have. These steps will be similar for a WSS installation.

The first thing you need when installing a Web Part is a site. To keep things clean, I am going to set up a separate site called code-magazine. You can set up this site using the following steps.

  1. Browse to the SharePoint Central Administration Web site (SCAW) by going to Control Panel | Administrative Tools | SharePoint 3.0 Central Administration.
  2. Within SCAW go to the Application Management tab, and under "SharePoint Web Application Management" click "Create or Extend a Web Application." When inside that page, click "Create a New Web Application."
  3. Fill in the necessary fields, I chose CodeMagArticle for the description and 42000 for the port.
  4. On the "Application Created" page, click the "Create Site Collection" link.
  5. Type "Code Magazine Article" as the title and use the "Collaboration | Blank site" template to get started. Also specify yourself, or the currently logged on user, as the administrator for that Web site.
Essentially what you have done in the above steps is create a Web application on port 42000 in IIS. Under this Web application, you have created a site collection with a top-level site based on the "Blank Site" template. You may browse to the site at this time, as shown in Figure 11. You should also notice a "Site Actions" link on the top, right-hand corner. If you click that link and choose "Edit Page," you see various WebPartZones on the page and a couple of Web Parts added to each WebPartZone, as shown in Figure 12. Clicking the "Add a Web Part" link brings up a list of Web Parts that this SharePoint Web application currently understands and is able to offer for use on this page (see Figure 13).

Figure 11: The Code Magazine Article site—without any customization.
Figure 12: The Code Magazine Article site—the front page in Edit mode.
Figure 13: The dialog box that lets you add new Web Parts in a specified WebPartZone.
The challenge is to make sure that the OPMLEditor and RSSRender WebParts appear in the list and work within SharePoint 2007.

To do so, you must first register the Web Part in the web.config file for the application that you are running on port 42000. Remember, this web.config affects all the sites in the site collection at port 42000, of which the Code Magazine Article site is at the root. So first you need to find the physical directory that the relevant web.config file lives in. You can easily find that by going to Control Panel, selecting Administrative Tools, selecting IIS Manager, and then looking for the CodeMagArticle site running on port 42000. In its properties, you would find the physical directory that virtual directory is running from. In my case it was C:\Inetpub\wwwroot\wss\VirtualDirectories\42000.

If you open the web.config that lives in that directory you will notice a <SafeControls> section. That's where you need to add information about your assemblies so SharePoint can begin to use them.

However, SharePoint must be physically able to access those assemblies. There are two easy ways to ensure that SharePoint should be able to access those assemblies: You can either choose to put the file in the GAC or you can put it in the bin directory. While the GAC is a simpler approach, bin is arguably a cleaner approach. It is important to note that putting assemblies in bin also requires you to do some extra work to make your Web Parts work under the default locked-down secure mode that SharePoint sites work in.

Note that I said SharePoint works under a default locked-down mode, specifically WSS_Minimal. If you poke around the config files on your system you'll find the specific rights WSS_Minimal confers. Even though the details of WSS_Minimal permissions are out of scope for this article, it is sufficient to say that a Web Part that makes a call to an external Web service (RSS) that lives on a separate domain will probably not work under default locked-down mode.

At this point, I have two choices: I could either use the GAC or specify custom security policies. Specifying custom security policies ultimately is a better way of doing things, but, to keep my life and this article simple, I am going to go with the GAC approach.

In a production environment, you could restrict the number of keys you use, and then use the keys as evidence to create a tiered-level security structure based on keys to keep things clean.
To deploy my assemblies in the GAC and use them throughout SharePoint, I need to do two things. First, I will need to strongly name my assemblies so they get a definite PublicKeyToken. This naming keeps things cleaner in the long run anyway. The easiest way to strongly name the class libraries follows:

  1. On the project item in Solution Explorer, right-click and select Properties.
  2. Under the Signing tab on the left, select the "Sign the Assembly" check box and specify a strong name key file.
In a production environment, you could restrict the number of keys you use, and then use the keys as evidence to create a tiered-level security structure based on keys to keep things clean.

Secondly, I will need to add the System.Security.AllowPartiallyTrustedCallers attribute to the AssemblyInfo.cs file in both assemblies, so partially trusted SharePoint code can use my assemblies.

Figure 14: Using Reflector to figure out the Assembly Signature string.
Now go ahead and build the two assemblies containing the Web Parts (and the communication and the custom editors), and then deploy them in the GAC using gacutil.exe.

Once you've deployed the assemblies to the GAC, you need to find the assembly signature string. You can piece together the assembly signature string using sn.exe, but I find the easiest way to find this string is to use Reflector. Run Reflector and open the two assemblies and you should find the assembly signature string in the status bar as shown in Figure 14. It is this assembly signature that you need to put in the <SafeControls> section of your SharePoint Web site.

So, for instance, you can add the Winsmarts.OPMLEditor WebPart using the following element in the web.config file's <SafeControls> element:

     Version=, Culture=neutral, 
     TypeName="*" Safe="True" />
Obviously, if you just copy/paste the above, it probably won't work—you need to specify the correct PublicKeyToken as generated on your machine.

Similarly, go ahead and add a SafeControl element for the Winsmarts.RSSRender assembly.

You may wonder what SafeControl has to do with the name "WebPart." As it turns out, this approach is not specific to just Web Parts. If you want to register a custom workflow or any other assembly, you have to use a similar approach.

After changing web.config you need to restart the application pool, or run iisreset.exe to restart IIS.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date