SerialSebOpenWrap’s view on versioning
There has been a bunch of questions regarding the differences between CoApp and OpenWrap when it comes to versioning. If you follow the blogs and that project, you know that they are planning to install everything in the GAC whenever packages are installed, and require everything to be Authenticode signed.
OpenWrap takes the opposite view, and discourages strong-naming your assemblies. The reason is very simple: in .net, whenever you update an assembly to a newer version, as long as the assembly is not strong-named, the assembly version is blissfully ignored, which lets people swap the dll around as and when needed, when there’s a fix / update available.
The only way to not break project references when packages are updated would be to never update the AssemblyVersion in an assembly, rendering the versioning scheme useless.
The alternative is to create policy redirections as part of the deployment to the GAC of a strong-named assembly, or for the consumer to add those redirections manually in each of their projects. Either way, it’s either a huge burden on publishers (and people don’t bother), or on the consumers (and people get angry). Either way, we’re still in unhappy land.
All this versioning is not needed, for the simple reason that OpenWrap has its own versioning scheme, per package, providing you with many more features than the 1-1 coupling provided by strong-named assemblies.
And finally, last but not least… If like me you believe very strongly in xcopy-friendly development and deployment, the GAC breaks all this: you now require the assemblies to be GAC’d on your build server and locally before you can use them, as otherwise any odd version already installed on the system would take over. And there lays the major pain point, the GAC takes over from your local references and there is *nothing* you can do about it.
As the goal of OpenWrap is to enable rapid development and update of packages, strong-naming assemblies and GAC’ing them is diametrically opposite to the vision of the tool, and as such will be discouraged. I’ll even put a big fat red warning if you take a dependency on a package that has assemblies already in the GAC, offering you in one swoop the option of removing them interactively. I may even provide the option to automatically strip out strong-naming from assemblies you try to package.
Help yourself and help versioning, say no to the GAC. If you do have scenarios where you believe strong-naming is the right solution, please leave a comment and we can discuss it.
[Note: Strong-naming has nothing to do with signing. Signing assembly code with a certificate is not useful to reduce malware (I don’t see how it would), and it pauses the risk of the certificate revocation being checked before being ran. But it has nothing to do with the key signing used in strong-naming, it’s a different process.]