Strongly named version?

[akwok]

Love the package but are there any plans to release a strong named version in the near future? Our project is strong named (due to upstream requirements) and we are unable to consume this unless it's also strong named.

I am aware of workarounds such as signing the assembly ourselves (or forking the project), but am hoping for something cleaner and less intrusive.

Thanks!

[Sternerson]

Seconding this. We are using a disassembly-reassembly step to sign the dll. Sort of breaks the nuget magic.

[caesay]

There's no need for a him to provide a signed version of the assembly and i seriously disagree with this. There are many tools which facilitate the automatic signing of nuget dependencies, some of which can also be consumed as a nuget package. No need for any manual steps. Once such tool is this: https://github.com/brutaldev/StrongNameSigner

Providing a signed version becomes much more of a problem - here is an example from personal experience: StackExchange.Redis, they offer both a regular and a strongly signed assembly, and other nuget packages choose which one to use seemingly at random. This means if you consume two other nuget packages, you might end up with SignalR which requires the StrongName version, and Hangfire which requires the unsigned version.

[frankshearar]

No one should ever publish both a signed and unsigned version of an assembly. They don't have the same name, so bindingRedirect doesn't work (or you have to bindingRedirect BOTH, and then you have a duplicate dependency on essentially the same package...).

But publishing an unsigned package makes it painful for those who have no choice but to sign their stuff. Yes, that's the consumer's problem, not the publisher's problem. But publishers should care very deeply about their consumers' problems.

[caesay]

Fwiw you can also take a look here for a nuget-only solution to this problem:
https://github.com/dsplaisted/strongnamer

[frankshearar]

Yep, StrongNamer is why I'm here :) It's great, and does what it says on the tin, but if A is not strong named, and B is, and C uses B... C also needs to use StrongNamer, to sign A.

Anyway, we have come up with an alternate plan.

[aidanbebbington]

I'm afraid I'm out of the .NET space right now, and the controversy around this one seems to just keep swirling, so I'm not sure I know enough to proceed. If someone's keen enough to whip up a pull request then I'll certainly take a look at it.

[twcclegg]

octokit/octokit.net#405