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

  • Live Event Date: December 11, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Market pressures to move more quickly and develop innovative applications are forcing organizations to rethink how they develop and release applications. The combination of public clouds and physical back-end infrastructures are a means to get applications out faster. However, these hybrid solutions complicate DevOps adoption, with application delivery pipelines that span across complex hybrid cloud and non-cloud environments. Check out this …

  • Due to internal controls and regulations, the amount of long term archival data is increasing every year. Since magnetic tape does not need to be periodically operated or connected to a power source, there will be no data loss because of performance degradation due to the drive actuator. Read this white paper to learn about a series of tests that determined magnetic tape is a reliable long-term storage solution for up to 30 years.

Most Popular Programming Stories

More for Developers

RSS Feeds