It is very simple to deploy an ASP.NET application, especially when compared to classic ASP. There is no registering of components in the Registry, no need to stop and start the server or the operating system, no problem with multiple versions of the same DLL for different applications, and no more DLL hell.
That’s the good news. There is no bad news, especially if you do not need to deploy assemblies globally.
ASP.NET derives all this deployment bliss by virtue of being part of the .NET Framework. The deployment features mentioned earlier are common to all applications developed under the .NET Framework.
There are actually two different ways to deploy applications. The first, XCOPYdeployment, is so simple as to cause experienced developers to ask, “Is that all there is to it?” It provides all the deployment benefits of .NET except for the ability to deploy assemblies globally (i.e., to use application code modules for multiple applications). In order to implement globally available code modules, you will use globaldeployment. Both deployment methods are described in more detail in the following sections.
An assembly is the .NET unit of versioning and deploying code modules. Strictly speaking, an assembly consists of Portable Executable (PE) files. PE files can be either DLLs or EXEs. These PE files are in exactly the same format as normal Windows PE files.
In ASP.NET, an assembly will typically consist of a single DLL, although it may consist ...