Resolving Class References to Assemblies

Assemblies are the unit of class deployment in the common language runtime. Developers writing .NET Framework classes using Visual Studio .NET version 7.0 will produce a new assembly with each Visual Studio project that they compile. Although it is possible to have an assembly span multiple portable executable (PE) files (several module DLLs), Visual Studio .NET will, by default, compile all assembly code into a single DLL (1 Visual Studio .NET project = 1 .NET Framework assembly = 1 physical DLL).

You can use an assembly on a computer by deploying it into an assembly cache. The assembly cache can be either global to a computer or local to a particular application. Only code intended to be shared across multiple applications should be placed in the global system assembly cache. Code specific to a particular application, such as most Web application logic, should be deployed in the application's local assembly cache. One advantage of deploying an assembly within an application's local assembly cache is that only code within that application can access it. (This is a nice feature for scenarios involving ISPs.) It also facilitates side-by-side versioning of the same application because classes are private to each application version instance.

An assembly can be deployed into an application's local assembly cache by simply copying, XCOPYing, or FTPing the appropriate files into a directory that has been marked as an "assembly cache location" for that particular application. No additional registration tool must be run once the appropriate files are copied, and no reboot is necessary. This eliminates some of the difficulties currently associated with deploying COM components within ASP applications (currently, an administrator must log on to the Web server locally and run Regsvr32.exe).

By default, an ASP.NET Framework application is automatically configured to use the \bin subdirectory, located immediately under the application root, as its local assembly cache. The \bin directory is also configured to deny any browser access so that a remote client cannot download and steal the code. The following example shows a possible directory layout for an ASP.NET application, where the \bin directory is immediately under the application root.
C:\inetpub\wwwroot Web.cfg Default.aspx \bin <= Application assembly cache directory MyPages.dll MyBizLogic.dll \order SubmitOrder.aspx OrderFailed.aspx \img HappyFace.gif
ASP.NET Framework application Startup and Class Resolution

ASP.NET Framework applications are lazily constructed the first time a client requests a URL resource from them. Each ASP.NET Framework application is launched within a unique application domain (AppDomain)--a new common language runtime construct that enables process hosts to provide extensive code, security, and configuration isolation at run time.

ASP.NET is responsible for manually creating an application domain when a new application is started. As part of this process, ASP.NET provides configuration settings for the common language runtime to use. These settings include:

* The directory paths that make up the local assembly cache. (Note: It is the .NET Framework application domain isolation architecture that allows each application to maintain its own local assembly cache.)
* The application's security restrictions (what the application can access on the system).

Because ASP.NET does not have compile-time knowledge of any applications you write on top of it, it cannot use static references to resolve and reference application code. Instead, ASP.NET must use a dynamic class/assembly resolution approach to make the transition from the ASP.NET runtime into application code.

Code Replacement

.NET Framework assemblies are typically compiled and deployed into a Windows DLL-based PE format. When the common language runtime's loader resolves a class implemented within this type of assembly, it calls the Windows LoadLibrary routine on the file (which locks its access on disk), and then maps the appropriate code data into memory for run-time execution. Once loaded, the DLL file will remain locked on disk until the application domain referencing it is either torn down or manually recycled.

Although ASP.NET cannot prevent the common language runtime from locking a loaded assembly DLL on disk, it can support you by ensuring that the physical DLLs in a Web application's private assembly cache are never actually loaded by the runtime. Instead, shadow copies of the assembly DLLs are made immediately prior to their use. These shadow assemblies--not the original files--are then locked and loaded by the runtime.

Because the original assembly files always remain unlocked, you are free to delete, replace, or rename them without cycling the Web server or having to use a registration utility. FTP and similar methods work just fine. ASP.NET maintains an active list of all assemblies loaded within a particular application's application domain and uses file-change monitoring code to watch for any updates to the original files.

(http://samples.gotdotnet.com/quickstart/aspplus/doc/deployment.aspx)

I hope you enjoyed the tutorial Happy programming !

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form