Strong Name Nightmare

[nick.d...@gmail.com]

I doubt this is the first time this has been brought up, but I could not find anyone requesting something similar.  I have hit a brick wall trying to resolve version conflicts in the many libraries we have that reference log4net, but that isn't the point of this post.  My main goal is to start a discussion about checking in a plain-old *.snk file with the project and let people both build and actually use a modified version of DotNetOpenAuth.

I work on a large system that has many, many dependencies, and some of them conflict when it comes to log4net.  As you probably already know, log4net changed their public key when they release 1.2.11, and this has been the source of my woes because it renders binding redirects via config files useless.  Yes, I know there are ways around this.  I can put it in the GAC or I can build a new version.  Well, the GAC thing could be made to work, but it is a giant PITA when it comes to deployment, and then I would have to worry about initializing both logging systems at runtime for it to be of any use.

What I wanted to do was build my own DNOA assembly that referenced the version of log4net that I needed.  However, because the project is setup to be delay signed and you don't seem to have distributed the private key, that is going to be painful.  This isn't quite DLL hell since at least I know what is going on and have a couple of paths out of it, but all those paths involve a lot of work for what seems like not very good reasons.

Why is DotNetOpenAuth setup like this?  It is supposed to be an open source project.  It builds and runs fine against log4net 1.2.10.  Why are we not free to build that and use it in our own code?

I'm sorry if my tone got too snippy there.  This is an awesome library and I appreciate the blood-sweat-and tears that must have gone into it.  I know that 'preventing others from touching my code' was never a goal of the strong name arrangement that the project uses, but it does create that situation, and the ability to inspect, debug, and customize libraries is supposed to be a feature of open source projects.  Yes, I know that I can technically give it a different strong name and just use that one, but that also means that I have to build everything that depends on DotNetOpenAuth against the new assembly, and everything that depends on them, and so-on.  When you consider that WebAPI has a dependency on it and then consider everything that depends on WebAPI, it is pretty obvious that the barrier to doing that is incredibly high in practice.

This is basically the same argument that cajoled log4net into changing their signature and distributing a *.snk file.  Unfortunately, they chose to change the key when they did that, which has led me to this post.

So how about it? Is this out-of-the-question?

thanks for all you've done,

Nick

P.S. If there exists a DNOA build that matches 'Version=4.3.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' and references log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821, and you tell me where to download it, I would be very appreciative.