To sign or not to sign an OSS project

At one point, AutoMapper was not a signed assembly. Until someone asked for it, I went ahead and signed the assembly, and really haven’t had a complaint since. But it seems that signing of OSS projects is a bit of a contentious position in the OSS world of .NET.

In this discussion on NuGet, I found Brad Wilson’s position on signing to be pretty much the same as mine:

Code signing is not a security measure. It’s not to support putting our assembly in the GAC (it actually doesn’t work in the GAC). It’s merely to satisfy those who have a requirement to sign their own code.

We’ve suffered zero reported problems from this strategy.

The reason the issue came up for me was that I started to use the library Should in the AutoMapper unit tests project. Guess what? It wasn’t signed. And guess what? Because it wasn’t signed, it was completely unusable for me. I had to download the source and modify the project to sign the assembly (even more fun with ILMerge in the mix).

The cons of signing basically center around the issue of versioning. When an assembly is signed, you have to use assembly binding redirects whenever you reference a new version without upgrading the others. For example:

  • A references B
  • B references C
  • A references C

If project A is my project, and I want to upgrade C, but I don’t own B (in most cases, this would be a fairly ubiquitous OSS library, such as log4net, Castle, StructureMap etc.), I have to use binding redirects to tell B to use the new version of C.

Annoying, yes.

With signed assemblies, I’m enabling all sorts of scenarios that absolutely require signed assemblies, such as

  • InternalsVisibleTo
  • Supporting signed assemblies (which require all references to be signed)
  • Some wacky medium trust environments

It’s definitely not the only strategy out there, as Sebastian Lambla has a great writeup on strong naming assemblies and OpenWrap. However, given the choice between annoying or unusable, I’ll go for annoying.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in AutoMapper. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • You needn`t to sign assemblies for usage of InternalsVisibleTo

  • Omer Mor

    Like Alexander said: You definitely don’y need to sign to use InternalsVisibleTo.
    From MSDN:
    Both the current assembly and the friend assembly must be unsigned, or both must be signed with a strong name.

  • Andy Alm

    What do you think of the idea of signing your assembly but not incrementing the AssemblyVersion with every release.  Maybe that gives you the best of both worlds: You don’t block people who have signed assemblies from consuming your library, but you also don’t put your consumers in binding redirect hell.  The one drawback is the AssemblyVersion doesn’t necessarily match the package version, but can’t you use the AssemblyFileVersion to indicate that?

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #917()

  • David A R Kemp

    You sign your test assemblies too? That’s commitment

    • Anonymous

      Only because I’m forced to :)

  • So whats the reasoning behind corporate policies for signing? I’ve found no compelling reason to sign assemblies of internal LOB apps.