Managing Resources in a Custom Web Part

Linked Resources

In some respects you might think that having linked resources is a bit of a backward step—you had to provide linked resources in the days prior to ASP.NET 2.0. Fortunately, the SharePoint architecture lends itself very well to referencing file system based resources, and provides methods to make this process easier and cleaner than before. Far from being backward, using linked resources provides the additional benefit of separating resources that may require modification (or that you know in advance will need regular updates) from the assembly and solution.

By default, SharePoint is aware of two file system based locations for storing linked resources. These have very similar URL’s but the physical files are deployed to entirely different locations.

1. siteroot/_wpresources
2. siteroot/wpresources

They map to following physical file locations:

1. C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensionswpresources
2. C:inetpubwwwrootwssVirtualDirectories80wpresources

Author's Note: The inetpub directory is usually installed in the root of C:, but it may be different on your installation. The 80 folder is the folder for your Web Application within the VirtualDirectories folder.

Option 1 is to be used only for assemblies deployed to the GAC (Global Assembly Cache). This virtual directory is available throughout your SharePoint farm. Option 2 is a folder within the web application configuration and hence is available only within a specific web application. You use this location for DLLs that will be deployed within the bin folder of your web application.

Author's Note: WSPBuilder and other tools will work out where your resources should reside on the file system, deploy the files there, and update the manifest.xml for you. The downloadable sample code accompanying this article uses WSPBuilder. A future article will cover how you can use this tool to generate your WSP files.

Once you have selected which wpresources folder you are going to need then you should create a sub-folder within that location.

• For GAC based assemblies in the _wpresources folder you need to follow this directory structure: namespaceversion__publickeytoken
• For bin-based assemblies in the wpresources folder you just need a folder named after the root namespace of your project.

After creating the sub-folder, copy all the required resource files into this location.

Now that your resources are in a location where you can reference them from within your web part, you need to be able to get a reference to them in your code. You could just reference them using the URL at which they are located, for example:

siteroot/wpresources/namespace/filename.ext

However, I prefer to use the SPWebPartManager class's GetClassResourcePath method. Given an SPWeb object and the type of your web part, this function returns the path to your resources. This is beneficial for two reasons:

1. You don’t need to remember which wpresources folder your resources are stored in as the method works that out for you.
2. In an upgrade scenario it is likely that this code will still work, whereas a direct reference to the URL might not.

The code for a call to this method within your web part class will look like this:

// in C#
SPWebPartManager.GetClassResourcePath(
   SPContext.Current.Web, this.GetType()) + "/";
' in VB
SPWebPartManager.GetClassResourcePath( _
   SPContext.Current.Web, Me.GetType) & "/"

You might find it useful to wrap this method call as a read-only property within your web part, because you will probably need to call the method many times within your class.

Embedded vs. Linked Resources—Which is Best?

There is no real hard and fast rule as to which of these methods is best for managing web part resources, however in my opinion, maintainability is the key. If you think that you will need to make changes to your resource files, then I would highly recommend using the linked approach. That way, your resources are separate from your assembly, and can be maintained without breaking your existing functionality or requiring a code rebuild. However, if your web part contains completely fixed resources, such as an image that is never going to change, or a small specific script that requires no maintenance, then by all means use embedded resources.

The Example Code

I have included both VB.NET and C# code in the downloadable sample code as well as a WSP (SharePoint solution package) file. The WSP installs a sample web part that uses both embedded and linked resource management techniques.

Both the VB.NET and C# projects are based on the WSPBuilder extensions for Visual Studio. These extensions support both 32- and 64-bit installations and work in both Visual Studio 2005 and 2008.