Strong Name

[SergeyBarskiy]

It would be nice to give assembly included in WebApiContrib.IoC.StructureMap package a strong name, just in case someone has a policy to sign all assemblies.
Thank you.

[panesofglass]

@ChrisMissal Thoughts on this? None of our packages are signed. I wouldn't want signed assemblies in most cases due to the problem of binding redirects when we push a new bug fix. We could offer a second package that is signed, but that means we have to maintain those two packages. I suppose another alternative would be to vary the assembly version and assembly file version to avoid the binding redirect issue.

Here's a good post on the topic: http://codebetter.com/sebastienlambla/2011/01/05/strong-naming-assemblies-and-openwrap/

[ChrisMissal]

I'm going to maintain a strong stance of "no" on this one. A few reasons:

1. The code for most of these (especially this one) is so small that it doesn't really even warrant an assembly. You could just drop the code in your project and maintain the namespace and license. The assembly on some is just for ease of installation via NuGet.
2. In my experience strong named assemblies create more headaches than they solve. The need for them comes from rules and regulations, not to make the developer's life any easier.
3. I don't want to predict that somebody is going to want anything specific on these, for now, I think we should stick to YAGNI.

Just my thoughts, I'm not trying to be a jerk about it, I just have a strong opinion.

[panesofglass]

Somewhat related: I've been wondering if we should offer *.Sources NuGet packages. That would solve this problem by allowing people to download from NuGet but build what they need how they need it.

[SergeyBarskiy]

While I agree with all the arguments against, I will only make one argument for signing - this DLL has a dependency on StructureMap DLL, which is actually signed.
Thanks again.

[warrenrumak]

That may not be relevant as StructureMap 3 is no longer signed and Jeremy Miller has made it clear that he has little interest in doing so.