VB .NET Tip: Assembly Deployment Best Practices

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.



About the Author

Bill Hatfield

Bill Hatfield is the best-selling author of numerous books for developers, including ASP.NET For Dummies, Active Server Pages For Dummies (on Classic ASP) and Visual InterDev For Dummies. He is also the editor of Visual Studio .NET Developer, a monthly technical journal from Pinnacle. He's an experienced corporate trainer and works in Indianapolis, IN where he also co-founded the local .NET group, the Indianapolis .NET Developers Association.

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

  • It's time high-level executives and IT compliance officers recognize and acknowledge the danger of malicious insiders, an increased attack surface and the potential for breaches caused by employee error or negligence. See why there is extra emphasis on insider threats.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds