Deployment

Windows users are aware that installing an application on Windows can be complicated. For example, an installation program may copy files to various subdirectories and may update various registry settings. Backing up such an application or moving it to a different machine is not easy, as you have to hunt down all the files (spread over various directories) as well as the relevant registry entries. Moreover, uninstalling the applications may leave some files or registry entries behind, making your machine very messy.

One of the goals of .NET deployment is to simplify installation.

In the simplest case, a stand-alone .NET executable, when copied to a machine on which the .NET Framework is already installed, can simply be executed. No registry entries are changed. Moreover, simply deleting the file removes the application.

If an application consists of more than one assembly, simply copying all the assemblies to a single directory is enough to make the application run. No modifications are needed to the registry. To uninstall the application, just delete the files. This kind of deployment is often referred to as XCOPY deployment.

Of course, a real application most likely will be packaged using other mechanisms such as .cab files (used in Internet downloads) or .msi files (used by the Windows Installer service). However, there is still no need to modify registry entries just to make the application run. Creating shortcut links on users' desktop or the Start menu may require changes to some registry entries, but this is more of a Windows issue and not specific to .NET deployment.

Assemblies that are deployed to the same directory as the application are called private assemblies, as the assembly files are not shared with any other application (unless the other application is also copied in the same directory, but this is rare). Private assemblies are a big win for trouble-free installation. When the application is run, the common language runtime checks the local directory first to load the required assembly. This means that the common language runtime will not load a different assembly that just happens to have the same name, thus preventing administrative problems.

Private assemblies need not always be installed in the same directory as the application. For better organization, they can be installed in any subdirectory under the directory that contains the application. In this case, however, .NET requires that a configuration file be supplied to indicate the path to pick the assemblies from.

The configuration file is an XML file with a name that is the filename of the application executable with .Config at the end. For example, if the application executable were HelloUser.exe, the configuration filename would be HelloUser.exe.Config. The file must be installed in the same directory as the application.

The configuration file provides a simple administrative control. As we will see in later chapters, there are many settings, such as those related to versioning and remoting, that are best decided by the user or administrator of the application. Such settings can be specified in this file.

The setting that we are concerned with here is called the PrivatePath setting. The following configuration shows how the common language runtime can be asked to look for private assemblies in a subdirectory called MyBin (Project Interfaces):

<?xml version="1.0"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <probing privatePath="MyBin"/>
    </assemblyBinding>
  </runtime>
</configuration>

Private assemblies should be used whenever possible. However, there are times when an assembly has to be installed such that it is shared with multiple applications. Things start getting a bit complicated in this case. In a later chapter, we will look at how shared assemblies are installed, locally, as well as when downloaded from the Internet.