Packaging Abilities about aspnetserve HOT 9 CLOSED

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.

[deleted comment]

[deleted comment]

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.re
gistervirtualpathprovider.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