I've been wanting to do it for a long while, and now seems like the right time to be planning. If you are in Australia, New Zealand, Tokyo, Singapore and can host me for an evening or a couple of days of training on ReST, nhibernate, distributed architectures, package management, software practices or just want me to hang around, please send me an email at seb@serialseb.com The more of you show an interest, the longer I'll stay. Let me know.

I’ve delayed slightly the tutorial on Part 2, as ready or not, I’m pushing binaries and the server online on the 26th of August. Call it a first preview. Delays are due to my really wanting some features that I didn’t think we would have for a first release, but I think it’s worth it, and is due to my frustration in having to deal with all the mechanics of building OpenWrap and it’s server itself.

Expect the second part of the guide sometime this week.

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.]