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

  • On-demand Event Event Date: September 10, 2014 Modern mobile applications connect systems-of-engagement (mobile apps) with systems-of-record (traditional IT) to deliver new and innovative business value. But the lifecycle for development of mobile apps is also new and different. Emerging trends in mobile development call for faster delivery of incremental features, coupled with feedback from the users of the app "in the wild." This loop of continuous delivery and continuous feedback is how the best mobile …

  • On-demand Event Event Date: July 22, 2014 In this WhatWorks analysis, John Pescatore examines a use case where end users had local administrative rights on their PCs and it had gotten out of hand for this Fortune 500 Energy and Utilities company. The compelling event that prompted the company to reexamine this situation was the migration to Windows 7. In Windows XP, a custom tool that allowed users one of three levels of administrative rights to their workstations would need to be replaced during the Windows …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds