Those of us using FxCop or Visual Studio's code analysis are well used to seeing the plaintive plea to strong name our assemblies. Strong names provide versioning and verification as well as allowing assemblies to be placed into the global assembly cache. They are generally a good thing.

But there's a problem. Like any type of code or message signing they require a keyset and that keyset should be kept secret. What happens in open source projects or in corporate environments? Ideally the strong naming should become part of the build process; but that requires the key files to be placed under source control where any developer has access to them. Microsoft's solution to this is delayed signing; which requires the public part of the key and the private part is used to sign the assembly after it's done. However that has it's own hoops to jump though; because the assembly ends up half signed you must exclude any delay signed assembly from strong name verification. This may be acceptable in a corporate environment, but for an open source environment it's not something I'm happy to ask people to do - as it opens the possibility for a malicious assembly to run amok.

For AntiCSRF I have ended up with a very nasty kludge, two solutions. The first solution is the one you see checked into codeplex, with no hint of strong naming at all. The second solution contains a WiX project to build the installer MSI and a copy of the main solution, this time with a strong name set in the project. Of course now I have to keep the copied project in sync with the main project; not a chore in this case but for larger projects it certainly will be.

There has to be a better way that this; so I've put a suggestion on Connect for VS2010. I have no doubt there's a more elegant solution than my suggestion but if you've ran into this problem then please go vote the suggestion up, add better ideas, anything to stop people having to have duplication projects and solutions.