I am currently enjoying real benefits from an ASP.Net 2.0 feature, called Web Resources, in a project that I am working on. So why not blog about it? However, unlike my usual dissertation-length blogs, this one is going to have to be more about how to get-in, use the feature, and get out.  

When looking-over the HTML generated by an ASP.Net 2.0 page, I discovered a number of mysterious links that looked something like this:
/web/WebResource.axd?d=02Izydq6n-lcgo63dmOZZ8UgQsQMwdKNaScqrnNZgT2bI5odv1Sqsezt8wKaveny-icvswUuLm3GsReVgjnulQ2&t=632618557271718856
I noticed that these were used for resources such as images used by the TreeView control, as well as resources like .js files containing client-side javascript.

So the questions that came to mind were, where do these resources live? And can I use the same publishing facility for resources of my own? A little quality time with reflector revealed the resources are assembly-embedded (or linked) manifest resources, and the publishing mechanism is the Web Resources mechanism.

This is very useful for DLL's that package custom ASP.Net controls, which require supporting (and static) resources of any kind.

Here is the model:

• Embed a resource of any kind (HTML document, .js file, .gif or .jpg files, etc.) in your assembly. Visual Studio tack's-on the default namespace for the project, so if the file's name was "mouse.gif", then the manifest resource's name would be something like this "MyNamespace.mouse.gif".
• Apply an assembly-level System.Web.UI.WebResource attribute, which declares the resource (by name) to be a web resource. This attribute serves the dual purposes of declaring the resources content-type (such as "image/gif"), as well as declaring to the system that it is safe (in security terms) to serve this resource to requesting clients. Here is what this attribute looks like in C# syntax:
  [assembly: System.Web.UI.WebResource(
     "MyNamespace.mouse.gif",
     "image/gif")]
• Finally, you need a URL to publish to the client, which it can use to request this resource from your application. A call to the ClientScriptManager.GetWebResourceURL method accomplishes this. Here is what that code might look like in a custom control:
  Page.ClientScript.GetWebResourceUrl(typeof(MyType), "MyNamespace.mouse.gif");
  The first argument provides the system a way to find the assembly where the resource lives. (Unlike with other "manifest resource getting API's" the type's namespace *is not* added to the string provided.) The second argument should be the fully qualified manifest resource name.

That's the feature, in a nutshell.

I see this feature as having clear benefits over using an ASHX to publish static resources. One major benefit is the ability to encapsulate everything into an assembly full of custom controls. And so, from the consuming application's perspective, no additional configuration is required to publish arbitrary resources from the page.

After reverse-engineering this feature for my own needs, I thought to google the topic, and turned-up this article by Victor Garcia Aprea. Maybe I should have googled first!

Cheers!