I run a a development team and we’re working on some functionality that we’re likely going to share between different projects. The problem is that part of the functionality are some adminstration pages that we want to be able to develop separately, deploy as part of customer’s. The requirements we have are roughly the following
- We can version the pages separately, so that when we patch the shared functionality, we don’t have to rebuild/redploy the entire site.
- We don’t have to copy files from one project (the project with shared functuionality) to another (the project that is customer specific).
- In our source control the customer’s website is really a separate project and not a branch of the project with shared functionality.
- The administration pages should be themed to the customer’s site and additional admin pages may be added custom for the customer’s website.
The best way, we figured, was to deploy the shared functionality as a seprate assembly, similar to a precompiled website. A precompiled website however is one thing, AFAIK you can’t dump two precompiled websites into the same application. I did figure out a way to deploy the site as an assembly, by putting the admin pages inside an assembly as an embedded resource. We then pull the pages out using a VirtualPathProvider. There are great implementations out there using the VirtualPathProvider, such as serving a website from a ZIP-file and from a database (which is what SharePoint does).
If you don’t know what a VirtualPathProvider is, let me quickly fill you in. When ASP.NET gets an aspx page for the first time, compiles that page and stores the result in a system directory. Only when you change the file will ASP.NET recompile the page. Now, the file system that ASP.NET gets the page from is virtualized, which means that ASP.NET does not know how the underlying file system is implemented. By default this is the normal Windows file system, but you can create a provider that uses another storage mechanism. As long as it works just like the file system, this will work fine. You can use a database, XML file, ZIP file, web service, or whatever as the underlying file system. All you have to do is create a few classes, including an implementation of the VirtualPathProvider, register the provider in global.asax, and you’re off. The great thing is that because you’re supplying ASP.NET with the page, your page benefits from ASP.NET (pre)compilation. This means that if you build a CMS with content in a database, the database is only hit the first time the page is requested and the content is compiled into the page.
So, what we can do is put the aspx pages inside an assembly as an embedded resource and serving the pages from there. Because the pages are inside a regular .NET assembly, it can be linked into a project and be updated when there is a patch, without affecting the application’s it is contained in. All we have to do is redeploy the assembly. It sounds a bit weird, but it actually works, as you can see in the attached demo (51.54 KB). Be aware that this is really just a demo. It is just meant to prove it works. The logic to get directories is flawed (which has something to do with the fact that directories are not preserved in embedded resources), and possibly more is. However, you can access the following pages:
- \NewFolder1\HTMLPage1.htm (only works in VS webserver or IIS7 in integrated mode)
Default.aspx is kind of funny, because the code behind class is compiled in the class and the page itself embedded. Enjoy!