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.