Deploying a Private Assembly

Private deployment results in an isolated application where the application is a directory tree. Everything that you need to run your application is self contained and a part of the directory structure that is designed into the application.

This is the simplest case. If possible, this is how you should deploy your application. With a private assembly, you simply copy the files to a unique directory and run the code from there. When the software needs to be upgraded, you create another directory and copy the new files to the new directory and run. The added overhead of the disk storage space for the two versions of your software is undoubtedly minimal, and your customer can easily switch between the two versions if the latest is not all it was supposed to be.

After you are sure you don't need the old version, you can remove it by simply deleting the directory where the old application resided. You don't need to unregister portions of your application because you did not register them in the first place. What are the advantages and disadvantages of private assemblies? The advantages of a private assembly are as follows:

• The installation procedure is simpler to perform and simpler to understand. After all, you are just copying files.

• All files both with and without strong names (signed and unsigned) are simply copied to an installation folder. You could have a directory structure like this:

  My Company

  Application

  1.0

  1.1

  1.2

• All code is private to your application. You don't have to worry about interactions with other software. It is harder for others to easily use and abuse your software. This is a security through obscurity approach.

• Other applications cannot early-bind to your assemblies. This is related to the previous bullet; you prevent others from using your software.

The disadvantages of a private assembly are as follows:

• Because a global area to look for an assembly is unavailable, and no registration process exists, assemblies are located by filename alone. This requires that all of the files be located so that they can be found. For a simple application, this might be easy; however, for a complex distributed application, it is sometimes difficult.

• If you need the equivalent of side-by-side applications, then you will have to do it yourself. You will probably have to design some type of version directory tree.

• It might be hard to locate and debug a problem assembly.

• You must verify the strong name every time the assembly is loaded. This can make the startup time of your application longer. If an assembly is loaded in the GAC, then the strong name is verified once when the assembly is entered into the GAC rather than every time the assembly is used.

• Because none of your code is shared, your application might have a larger working set than it would if all or part of it were shared.