Sign LibGit2Sharp.dll by a strong name

[kostrse]

VSPackage (Visual Studio extensions) development requires usage of strongly-named assemblies. As result, NuGet package version of the library cannot be used out of box in such scenarios.

It would be very helpful to add singing of the library on the build server and distribute the signed version. As it would solve my problem, also it give ability to distinguish the "official" releases from custom built binaries by other members of community.

The process of signing can be made absolutely transparent: private key can be stored on a build server, as well as *.csproj files can be patched with necessary strong name properties directly during CI build.

I can provide all the necessary information how to implement this and help with modification of MSBuild script.

Thanks,

[AArnott]

I don't understand why folks are so pushy against the idea. They have nothing to gain from resisting it. The folks who want it strong-name signed have much to gain if it happens, and yet the opposition has nothing to lose or gain either way. So what is it to them? Why make it so hard (and waste 9 days, @thecodejunkie) making a fight over what should be a simple decision?

As was originally mentioned, the only possible downside to signing this package is the potential for wanting it to take a dependency on some other package that is not yet signed. That was said then, and it's still now the only downside mentioned on this whole thread. So please, let's end the debate and just let the project owners make a decision based on their roadmap and likelihood to take such a dependency.

[davepermen]

with even people from the asp.net team (amongst others) fighting against that dissease spreading any further, maybe, just maybe, there's a point in fighting signing, @shana.

and yes, @AArnott we gain from not having a signed version. as a lot of people will have a harder life by having the signed version pulled in. as it happened times and times before. this is not the first time this topic exist. it, sadly, won't be the last time.

don't sign. it's the only right thing to do. if you need it, do it YOURSELF. for YOUR needs.

[AArnott]

@davepermen Please tell us how it makes your life harder if this is signed.

[mythz]

I don't understand why folks are so pushy against the idea. They have nothing to gain from resisting it.

It's not an idea, it's an imposition that a minority of users are demanding of an external project to have their preference imposed on its entire user-base. This is a decision that's solely up to the project maintainers, you may request the change, but you shouldn't feel it's your right to demand it or expect project maintainers to action it.

It's irrelevant what reasons .NET OSS projects have to not want to sign their builds, they have their own experience and can make their own judgement. It's likely their primary focus is not your use-case, that doesn't mean you should try force them to accommodate your use-case, but it's a good indication that it might be time to hit the [Fork] button and sign your own builds.

Thanks to the easily reproducible nature of software, this effort only needs to be done by 1 volunteer who can then share their signed builds for everyone who wants it, to enjoy - whilst not affecting anyone who doesn't.

[AArnott]

@mythz I don't think anyone here is trying to force this project to sign. That would be fruitless. What boggles my mind is that so many folks who are not project committers will swoop in on issues like these filed on random GitHub projects and push against the idea as if it were either technically a bad idea or against their religion. It is the opposition that seems to be trying to force the issue. We're making the request, and defending it against arguments that sound hollow, biased and ill-founded. If we refuse to accept the opposition's hollow arguments, that isn't us trying to force the project owners to one decision or another. We're just pointing out the lack of substance in the opposition's arguments.

[olivier-spinelli]

@AArnott: thanks for your comment (english not being not my mother tongue, it sometimes hard for me to debate).

@thecodejunkie

Nuget was never designed to be a single-repository design.

Oups! One "minor" detail: the namespace! The name of the package is its name. Multiple sources with conflicting names "LibGit2Sharp.Strong" will be a mess. So I'll put "MyCompany.LibGit2Sharp.Strong" and so will do all the guys like me that needs one... and we'll end up with multiple packaging of the same version. And the Kittens will die.

[damianh]

@davidebbo WebActivator has had 6 minor releases all of which has a signed version of 2.0.0. of course you've had no problems with strong name because your version never actually changed! Release a 2.1 or a 3.0 and then see what happens.

Oh, strong naming is broken, lets use assembly binding redirect to bypass it! Paper over cracks?

I'm willing to wager the majority of pro-signing advocates are commercial concerns. So here's an idea, pay the oss maintainers to produce a signed lib for you. Afaik @paulcbetts has received ZERO for his offer of said thus far.

[damianh]

@davepermen Please tell us how it makes your life harder if this is signed.

@AArnott two libs with a transitive dependency on the same signed lib = hell. Non deterministic assembly loading order. Random runtime exceptions. Lovely!

[dsplaisted]

@davepermen Please tell us how it makes your life harder if this is signed.

@AArnott two libs with a transitive dependency on the same signed lib = hell. Non deterministic assembly loading order. Random runtime exceptions. Lovely!

@damianh If you've got a transitive dependency on two different versions, then what you probably want is to use the higher version. With strong names, you need binding redirects to do this, but as of VS 2013, MSBuild will do this for you automatically.

With that in mind, how are transitive dependencies with different versions any worse with strong names than without them? I'd only expect you to run into problems if the newer version of the library broke compatibility with the old one, but you would have run into the same problem without strong names.

[phillip-haydon]

Jesus christ can we stop signing stuff. It's so painful it makes me want to self immolation.

of GOOD reasons to sign: 0

Either IL Merge the unsigned assemblies into your project for use, or sign the assemblies yourself as a build step, or setup your own build to sign them.

---

This thread should be closed and locked.

[davidebbo]

The lack of unfounded fears and misunderstandings about strong naming has reached fever pitch in this thread :)

Here is a simple challenge for you: name one negative thing about JSON.NET being strong named (with a fixed version as discussed above), compared to it not being strong named. I'm talking about a concrete tangible thing that makes it worse for consumers of that assembly. I have not seen one in this thread, so I'm curious if there is anything behind all the great passion ;)

[phillip-haydon]

Wouldn't know, after all the pain I had with JSON.NET after it was signed with RavenDB/Nancy etc. I stopped using it. I haven't used it since V5 in my personal projects.

We use it at work but we IL Merge it because we get version conflicts between our two applications and a shared assembly between them. By IL Merging and internalizing we effectively have 2 versions. What ever shitty version MVC or WebAPI is using, + the version our shared assembly is dependent on.

[davidebbo]

The version conflict situation would happen equally if it was not strong named. So lots of passion, but no concrete argument against it being strong named. Anyone?

[JamesNK]

RavenDB's issues were caused by it requiring the pre ISO dates version of Json.NET and Web API requiring the post ISO dates version of Json.NET. It had nothing to do with strong naming.

I don't want to defend strong naming, it's caused a lot of problems, but if you're going to argue against it could you at least understand it?

Also this is the only strong naming related Json.NET issue (I think) that I know of, and it's pretty specific to Json.NET's unbiqidious nature: https://connect.microsoft.com/VisualStudio/feedback/details/816725/visual-studio-referencing-dll-in-c-program-files-x86-microsoft-visual-studio-12-0-blend-directory-incorrectly

[carlosmn]

The core team is discussing this in a more private forum (for reasons which should be apparent from this thread) and we will continue to discuss and think about it and what it would mean for taking on dependencies.

Some good technical points were raised, but the discussion has veered off into what looks more like a shouting match. Thanks to all who have been clearing up misconceptions and remained civil.

@phillip-haydon the form of rhetoric you are using is not conductive to discussion and is not welcome here; showing up to a thread on a public forum swearing is not acceptable behaviour.

As it happens, different members of the team have been on holiday lately, so there hasn't been time to discuss the newer arguments and it's going to take a while for us to be able to reach a consensus.

This is an issue where feels are plentiful, as has been pointed out. I'm locking this issue to avoid it careering off further before we're ready to look at the arguments.