The topic has come up many times, and that is “Why do I have to register aspNETserve.Core.dll in the GAC to run aspNETserve?”. The answer to this question has to do with how aspNETserve uses the ASP.NET hosting facilities, so first some background information.

Background

aspNETserve internally makes use of the System.Web.Hosting namespace to manage AppDomains. Internal to aspNETserve is a class called DomainHook in the aspNETserve.Core namespace. When aspNETserve requests an AppDomain to be created it requests that a DomainHook be instantiated inside that AppDomain so that some level of interaction can occur between the two domains. This interaction is primarily focused around the processing of ASP.NET requests.

The only snag to this whole process is the method that aspNETserve uses to create the AppDomains, ApplicationManager.CreateObject, makes you specify the physical path to the ASP.NET application. As it turns out the physical path is also used for the BaseDirectory property of the AppDomain to specify/limit which paths to probe for DLL resolution. This is precisely where the GAC requirement comes from.

Since the hosted web application probably does not contain aspNETserve.Core.dll in its bin directory, then the only other way to successfully load that assembly, to instantiate the DomainHook type, is by placing the assembly in the GAC.

Solution

Currently aspNETserve has an open task of officially finding a work around to the above described scenario that removes the GAC installation requirement. However, in the interim, a quick and easy solution is to simply place the aspNETserve.Core assembly in the bin directory of the web site you wish to host. While not elegant by any means, it is something.