Have you ever wanted to break up that monolithic web project into multiple projects, or reuse those user controls and web forms in multiple web projects?
Currently, reusing web forms and user controls in multiple ASP.NET projects requires copying the associated aspx and ascx pages. You can put web controls in separate assemblies, but you lose the design-time drag and drop that makes user controls and web forms so easy to create in the first place. If you've ever tried to put a user control or web form in a separate assembly, you probably ended up with a blank page or runtime errors. The reason is because
LoadControl() actually reads the ascx or aspx file to populate the
Controls collection and then binds them to your class variables. If the ascx file is not found, no controls are added unless you have done so in your code (as is done with WebControls).
What I wanted was the ability to dynamically call
LoadControl() from another assembly to reuse user controls in multiple web projects without copying a bunch of ascx files around. Too much to ask?
Would it be possible to embed those ascx and aspx files as assembly resources and then load them?
LoadControl() expects a virtual path, and there did not appear to be any way to load a control from a resource stream. Then I found this:
- How to use virtual path providers to dynamically load and compile content from virtual paths in ASP.NET 2.0
The Virtual Path Provider in ASP.NET 2.0 can be used to load ascx files from a location of your choosing. For my purposes I've decided to store the ascx files in the assembly itself. No more outdated ascx pages that don't work with the updated assembly. Only one file to deploy, the assembly itself, and if you add the assembly as a reference, VS will copy it automatically! To do embed the ascx/aspx file into the assembly, you must change the Build Action of the file on the property page to Embedded Resource, the virtual path provider we create will do the rest.
When a Virtual Path needs to be resolved, ASP.NET will ask the most recently registered Virtual Path Provider if the file exists, and if it does, it will call
GetFile to obtain the
Before we can load a resource, we need to know what assembly the resource is located in and the name of the resource to load. I've chosen to encode this information into the virtual path. My final URL looks like this:
It's a bit lengthy, but it includes all the information I need. I don't want to intercept all URLs, so we need to be able to identify which URLs to process and which ones to let the default virtual path provider handle. To do this, I've chosen to process only URLs located in App_Resources. This folder doesn't exist, and that's the point as all paths at this location will be intercepted. The second part contains the assembly name, and the final part is the resource name, which includes the namespace.
I've implemented the Virtual Provider as follows:
IsAppResource is a private helper method used to determine if we should process the request or let the default provider process the request. Virtual Path Providers are chained together, so it is important that you call the base class. It was also necessary to override
GetCacheDependency to return
null, otherwise ASP.NET will try to monitor the file for changes and raise a
FileNotFound exception. Notice that
GetFile returns an instance of
AssemblyResourceVirtualFile, this class provides an
Open() method to get the resource stream, and is implemented as follows:
- Why Agile As We Know It Will Disappear
- SWAM: When LinkedIn Locks Down Social Networking
- Intranet Search: Where Documents Go to Die or KM Enabler?
- The Metamorphosis of the Social Enterprise
- Pivotal Revs Its Big Data Play, But There's a Better Story
- Just How Badly Does Microsoft Want Your OneDrive Biz?
- Does Cloudera Need to Cool It?