Component Versioning Proposal

I'm working on an article (well, one of several that I am currently working on) about how to handle versioning in .NET. This is sparked by several threads about handling Framework versions, and my experiences with Xheo beta testing their components. Paul Alexander and I have a great relationship in regards to the software we write. Neither one of us has fully taken advantage of the situation we created for ourselves, but hopefully that will change in the very near future.

Anyway, I have come up with a versioning policy that extends from Paul's suggestions, and takes into account Framework versions as well. I think it is an extremely responsible solution, and I would like opinions on the matter. I intend to have my article finished next week, and I'm hoping to have you guys join me in making this a standard.

Basically, it boils down to this: Responsible component developers really should have a release compiled to each version of the Framework. IMO it's the right thing to do, in terms of performance and so forth. NOW, this might cause problems in regards to the GAC and so forth. In the AssemblyInfo.* file, there are several attributes that tell the File System and the GAC how to handle things. The primary one is the <Assembly: AssemblyVersion> attribute. Usually this value is set to something like "1.0.*", which causes the end to be totally random. When you browse your assemblies in Windows Explorer, under the name it shows the version, which will usually end up something grotesque like "1.0.3452.45678" This is one of my biggest beefs with Aspose, because their component versioning is horrid. But I digress.

My proposal is that vendors start versioning their .NET components just like we've versioned programs in the past... Like GenX.NET 3.0 and so forth. So the first part of my AssemblyVersion attribute would be like "3.0...". The next part is the kicker. With MS Framework assemblies, they come in 2 versions (usually). .NET 1.0 assemblies are versioned 1.0.3300. .NET 1.1 assemblies are versioned 1.0.5000. So, Your component's major and minor version numbers come from the component version itself, but the revision number is the version of the Framework that the assembly is compiled to. Example: GenX.NET 3.0 for .NET 1.1 = "3.0.5000". This way, when you're browsing assemblies in VS.NET, you see the similarities right there, and it would take very little instruction to have your users recognize the difference.

Now, say you're like Xheo, and you release updates to your components frequently. These are minor fixes that can hardly justify a new minor build mumber. Well, you don't want to change the revision number, because that's the .NET version pointer. Instead, add an <Assembly:AssemblyFileVersion> Attribute to the AssemblyInfo.* file. This controls the version that Windows Explorer displays when viewing the assembly information. Also, now you can XCopy the new assembly up to your app without breaking the assembly references.

A few unsolved problems still remain. I still think that .NET needs an Application Assembly Cache for each application, so that then you can use multiple versions of an assembly with the same name in the app. ALSO, VS.NET needs to be able to connect to a remote server's GAC or AAC so that web hosting providers can provide components without having to redestribute the assemblies. You install it once, and it's available for all.

That's pretty much it for now. I am going to be expounding on this in much more detail in my article,  but this is the just of my idea. I'd lov e some feedback before I go to press with it.

6 Comments

  • The problem with using the assembly file version is that it's not really used by the CLR for versioning issues. Say you have a no-touch app that's loaded via an href.. the dlls are pulled into the machine's downloaded assembly cache. If you update one of the dlls, but only update the fileversion attribute, then the CLR will NOT download the new dll, and you'll have some clients running with the new version (those that cleared the download cache, or those that never ran the app before), and some running the old. Ouch.

  • It sounds like you are not advocating bindingRedirect, or publisher policy files when you patch a component. Simply drop in a new one right over the top of the old one.





    Also, I'm not convinced that having the AssebblyVersion and the AssemblyFileVersion say 2 different things is the best idea.





    I also agree that it makes sense to maintain separate versions of components for different frameworks. You might want to cover having two different project files that point at some of the same source files as a way to share common code, and not have 2 completely separate source bases to maintain.

  • Well, I think making your end users manage binding redirects and distributing publisher policy files is a little much to make your end users deal with. Besides, I don't want a component vendor telling me which version of the component I should use. It's my decision most of the time, not theirs. Besides, it kinda negates the idea of XCOPY deployment if you have to modify the web.config or register a new assembly in the GAC as part of the deployment process.





    Well, I know that the AssemblyFileVersion attribute is not used for the CLR, it's for YOU to be able to tell the difference.





    I'm not really talking about mo-touch deployment scenarios. While I think no-touch is really cool, I don't think it's advisable in a server control situation. I'm mostly yalking about server controls, where you have redistributables available for download off the web.

  • I also agree that it makes sense to maintain separate versions of components for different frameworks. You might want to cover having two different project files that point at some of the same source files as a way to share common code, and not have 2 completely separate source bases to maintain.

  • I work on the Visual Basic language team and am working with the .NET Framework on guidelines for component versioning. The long-term direction we're thinking about is different from what you are suggesting--since there are some additional issues that we mean to address. There should be something made public for component developers by the time Whidbey Visual Studio is released.



    I've been collecting a list of the top issues from developers surrounding component versioning, or related issues such as side-by-side Frameworks. (For example, we will not recommend using star, e.g. 1.0.*, in your version number. The star doesn't generate a random number, but is not easily human readable.) We will recommend strong-name signing. I don't have much data on how many developers are strong-naming vs. not.



    It would be great if you or your blog readers could post specific problems they or their customers are facing, how they are working around these today.

  • I am facing problem to work with old version of assembly in windows application. But all thew time it is defaulty taking new version. I read that medn version number in shared assembly but i didn't get that how that will be used of configuration to access old version

    Thaking you

    jyoti

Comments have been disabled for this content.