Was supposed to post this a while back

A while back, I discussed versioning issues with a couple of guys from Microsoft. They made some pretty important points, so I will detail them here:
  • 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, thus you would need to deploy an assembly for each framework version you supported.
  • [MS] recommends that you create a version of your control(s) for each framework version (for which the implementation differs), 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.

Here is the policy that we have adopted for GenX.NET 3.0, and will be using in the future on all components:

Marketing Website:
Add a new section called "Requirements". Use the following verbage: 
    Version 3.0.3300 requires Microsoft .NET Framework 1.0.
    Version 3.0.5000 is enhanced for Microsoft .NET Framework 1.1.

 For an example, see the pre-release version of the GenX.NET 3.0 website.

Component code for .NET 1.1-compiled version: - AssemblyInfo.* 
<Assembly: AssemblyTitle("GenX.NET 3.0 for .NET 1.1")>

What this does is display the Framework compatibility information right in the AssemblyTitle, which is what the "Add References" dialog displays as the name in VS.NET. At that point, it's pretty much a no-brainer to the end user which one they should use. ALSO, VS.NET 2003 usually hides 1.0 assemblies from that dialog box anyways, so you don't really have to worry about that. In the AssemblyInfo file, VS.NET automatically inserts comments about versioning. Now, it reads:

' Version information for an assembly consists of the following four values:
' Major Version
' Minor Version
' Build Number
' Revision

I have changed this policy to read as follows:
   Major Version
   Minor Version
   Framework Version
   Build/Revision

I also add an AssemblyFileVersion attribute to the assembly, and I follow the original versioning guidelines.

<Assembly: AssemblyVersion("3.0.4322.1099")>
<Assembly: AssemblyFileVersion("3.0.1099.0")>

The result is that the AssemblyVersion will display the Framework compatibility in the "Add References" version column, and Windows Explorer will reference my desired version when you right click it and select "Properties", or when you view the files in "Tiles" view. Not only is this consistent with Microsoft's versioning policy for Framework assemblies, but it also allows you to release bug fixes without skewing the manifest files of any projects that use your component. You can just change the revision number on the AssemblyFileVersion attribute to reflect the update, and XCOPY deploy the new assembly version in the /bin folder.

Paul at Xheo.com and I will be pushing this technique in various ways in the near future. I would invite you all to evaluate it and post your comments. I think it is a well-thought-out standard that should be adopted by the whole component-developing community, for the sake of our fellow developers and end users.

6 Comments

  • That's all fine what MS thinks I should do but what I think MS should do is make their IDE able to work with older CLR's so people can choose a new IDE while writing a control for 1.0 or 1.1. MS didn't even bother creating a config file for a library so a library can be made runnable on 1.0 with redirects.

  • Interesting - I really think that this will make life a whole lot easier for your customers. Of course, you have the advantage that your customers are developers, and all of this will automatically make clear and logical sense to them... What are you going to do for your 'less rational customers?'


  • How many of anyone's non-developer customers really care what version number you're using internally? Besides, IMO you can only do so much for people.

  • Appreciate the post - wish their were more like this amongst the increasing noise. One comment I would make is about &quot;Version 3.0.5000 is enhanced for Microsoft .NET Framework 1.1&quot;. This statement invites the question from a layman - what is enhanced - what does it mean? I think it is better to be authoritative and simply say &quot;Version 3.0.5000 requires Microsoft .NET Framework 1.1&quot;

  • Because we update the code for each version to take advantage of the enhancements of that framework version. it's subliminal thing to get them to upgrade to 1.1.

  • Also, I want them to be able to ask that question... because .NET 1.1 is so much better than 1.0... I want them to convert ASAP.

Comments have been disabled for this content.