Developing components: Assembly identification

With the release of .NET Framework 1.1, the version associated with your applications became an essential piece of information for your users. Take advantage of several features included in .NET to make versioning easier to determine and communicate.

With the release of version 1.1 of the .NET Framework, there was an uproar among the .NET heavyweights on component versioning and the Framework. Now, developers have always dealt with these issues (read: DLL Hell). Unfortunately, they'll never completely go away (read: Assembly Hell). The .NET Framework, however, attempts to make it easier through methodologies such as Strong Name Signing, and systems such as the Global Assembly Cache. I'll show you a simple and concise method of dealing with these issues, building on the same techniques that Microsoft uses.

In conducting research for this article, I had a conversation with several individuals at Microsoft. They made some pretty important points:
  • "You should not (and will not, in the future) be able to load an assembly in a CLR version older than the version in which it was compiled; you would need to deploy an assembly for each framework version you supported."
  • "[Microsoft] recommends that you create a version of your control(s) for each Framework version, and then allow the user to choose which of them to install. This will require more user sophistication when they start targeting a new Framework version, but, on the other hand, users can continue using your 1.0 implementation with the 1.1 framework if they don't know how to add the redirect or reference the new assembly."

This is probably news to many of you, but if you think about it, it makes sense. Would you really try to open a VB7 application in VB6? So why would you expect the VB6 runtime to run a VB7 app? So many people got upset over the Framework compatibility issue, they forgot how dependent their old VB apps were on specific versions of the VB Runtime (read: .NET Framework).

So, before we go any further, I'd like to point out how Microsoft versions its Framework assemblies. Open any project in VS.NET, right-click on the project in the Solution Explorer, and click Add Reference. You should see a screen similar to Figure A, with the assembly name in the first column, the version in the second column, and the path in the third.

Figure A
Add Reference Dialog in VS.NET 2003

If you're in VS.NET 2002, System.dll and all its Framework friends will display the version "1.0.3300.0". If you're in VS.NET 2003, they'll read "1.0.5000.0". This is a very important point, so remember it—it will come in handy in a minute.

One final point about this dialog: VS.NET 2003 will not display Framework assemblies for version 1.0. This is a departure from the Final Beta of VS.NET 2003 (codenamed Everett). If you were involved in that beta, you remember that it showed both versions by default. If you wish to reference older versions of the assemblies (WARNING: NOT RECOMMENDED), you have to browse for them manually.

Editor's Picks

Free Newsletters, In your Inbox