Deployment issues often get swept aside when deadlines overtake you and getting it out the door is all that matters. But, if maintaining the code is also a consideration, you’d do well to take note of the following assembly deployment best practices.
Don’t Keep Your Assemblies Small
You might think that dividing your assemblies up into little pieces would be the best approach. It assures that only the pieces that are necessary to complete a given task are loaded. However, this approach has a downside: The CLR loads large assemblies much faster and more efficiently than it juggles numerous small assemblies. You also are more likely to optimize your code better as one large assembly.
So, should you bundle all your applications into monolithic EXE files? Of course not! Map out the pieces that commonly work together and then carve your application up into fairly large chunks that are likely to load independently of other chunks. This approach usually provides the best balance.
Use Strong Names for Your Assemblies
A strong name is a unique identifier for your assembly. It includes the assembly’s name, the version number, the certificate of the developer, and a hash number. The certificate allows you to identify yourself and the CLR to verify you are the one who created it.
In addition, the hash can be used to verify that no one has tampered with the file since you created it. How? The hash is a single number that is a mathematical representation of your entire file. It is created when you assign a strong name to your assembly. Then when the CLR loads up your assembly to run it, it sweeps through your file again to create its own hash. It then compares its hash with the one stored in the assembly. If they are different, the CLR knows that the file has been tampered with since it was created—and the CLR will refuse to run it.
Another benefit of giving your assemblies a strong name is that, once you do, it’s easy to install your assembly in the Global Assembly Cache (GAC). Which leads to the next best practice…
Put Shared Assemblies in the GAC
By default, any assemblies that you use are private. This means that they are copied to your application’s bin folder when it is deployed. If another application also uses that assembly, it uses its own and won’t share yours. To make an assembly available globally, you have to store it in the deployment target’s GAC, which is just a centralized repository for common, shared assemblies. You can’t store an assembly in the GAC unless it has a strong name because the strong name is used to uniquely identify each item in the GAC. Even two versions of the same assembly are recognized as different because the strong names include their version numbers.
Use Version Numbers
Speaking of version numbers, be sure to use them. Each time you deploy a new release, increase the version number and re-create the strong name for your assembly. That will assure that everyone is clear on which assembly does what and makes it possible for some applications to use the previous version while other applications use the new version. You’ll find the version number specified in the AssemblyVersion attribute in the AssemblyInfo.vb file.