This should be classified under "enhancement" -- I would like to see some way of packaging an entire asp.net web application into a single file.

If you're familiar w/ java web applications, you can package them into a WAR (web archive) and then deploy that to the java web server. You can essentially accomplish the same thing you're doing here by using a container such as jetty and using a WAR.

I was hoping there would be a way of packaging an entire web application into a file like a WAR. Perhaps a zip file w/ no compression?

That way, I don't have to distribute or make my files easily available to the casual observer. IOW, I don't want people poking around my embedded asp.net pages. Plus it's much, much easier to package into an install if I don't have to worry about 500 files.

Any thoughts?

I like the idea. I had kicked around a similar idea, but instead of zip files I was considering embedding resources like .JPEG, etc, into a deployable DLL.

Although your idea of zip files, sounds like it would be cleaner. Plus I am not sure how well a .NET assembly would behave with hundreds of embedded web resources, which can get quit large.

I am not exactly sure how to implement this, as it is the ASP.NET components built into .NET that are accessing the physical .aspx (and other resources) on disk. Perhaps with a little work that is a piece of functionality that can be overridden with some custom logic.

Comment deleted

Comment deleted

It appears that this may actually be easier than I feared. The System.Web.Hosting namespace has a concept of a VirtualPathProvider that may lend itself nicely for this task.

To register a VirtualPathProvider see http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.registervirtualpathprovider.aspx

The only issue I see is:

You cannot store ASP.NET application folders or files that generate application- level assemblies in a virtual file system. This includes:

• The Global.asax file.

• Web.config files.

• Site map data files used by the XmlSiteMapProvider.

• Directories that contain application assemblies or that generate application assemblies: Bin, App_Code, App_GlobalResources, any App_LocalResources.

• The application data folder, App_Data.

Yeah,

so it sounds like that idea wasn't as good as I had hoped... but what do you think of this:

You create your "WAR" archive of the site as you had proposed, point aspNETserve to that as the site's physical root and start the service. Behind the scenes the server extracts the archive to a temporary directory and actually uses that as the application root.

Additionally a FileWatcherMonitor could monitor the WAR file to changes, and restart the app pool if any changes occur, for much the same reasoning that modifying the web.config would normally make such an event occur.

Additionally since this is sounding very doable (one way or another), I am going ahead and assigning this to release 1.3.

To me, it's more a problem of being able to package everything into one file. With the VirtualPathProvider, I still have to keep some files separate.

You might be able to do it by first creating another app domain, unzipping the config file to a temp dir, setting the configuration file, and then loading the site inside of it. This would also allow you to support hosting multiple sites as well and redeploying as neeeded.

For the assemblies, just setup an assembly resolver that will search and then load assemblies from the zip file.

Anything that needs to be compiled could be read and compiled into the temp dir and then use the assembly resolver to load it when needed.

I completely understand where you are coming from on this one. I am going to tackle this in the manor you were suggesting in your last comment, about unzipping to a temp directory.

I am changing the status of this task to started to reflect the fact that I am correctly working on this issue.

I will keep you updated as things progress.

The initial support for Web Application Packages (WAP), as I have called them, has now been completed. In its initial state there is a WebApplicationPackage class in the aspNETserve namespace that can be used to consume WAPs in custom code. Additionally the SimpleWebServer sample has been updated to support WAPs.

I have also created a wiki page describing WAPs in more detail, located @ http://code.google.com/p/aspnetserve/wiki/WebApplicationPackages