Strong Name

[ResiEvil]

Is it possible to strong name the assemblies?

Many Thanks

[vkhorikov]

I would prefer not to strong name the package. Could this help it your situation: https://github.com/dsplaisted/strongnamer ?

[Ironbell]

Worked like a charm and solved the problem for me. Thank you very much!

[yakimovim]

What is the reason why you don't want to sign the assembly? It is not very convenient to use two NuGet packages (yours and StrongNamer) instead of one.

[vkhorikov]

It's mostly a relic from the older MS days: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md#1-microsoft-strong-names-their-assemblies-should-i

[rizksobhi]

StrongNamer is causing great issues. In my situation, the only way to use your library is when it's signed. Thanks

[vkhorikov]

I plan to release a signed version of the library, similar to how Dapper does it. But I don't have an ETA yet unfortunately.

[adcorduneanu]

Vladimir, I don't find your reasoning for non-signing strong enough, but more like a personal flavor on your side. I would prefer working with a strong name assembly every day as this gives some assurance that nobody tampered with the existing implementation, as it will require the original key to sign it. In most companies, there are policies in place that will require this one, together with a digital signature (signtool.exe).

The community should have priority in detriment of flavors.

Having the key in is actually a minimal effort, compared with the possibility of searching for a drop-in replacement for any unsigned library, unbundling the existing package and signing it internally, or using some kind of unsecure NuGet that will do the signature for you.

I would like to see it in the very next release if possible.

[vkhorikov]

Well, I did change my opinion, see my last comment.

[bothzoli]

Hey @vkhorikov,
I have created a PR (#543) to address this issue.
Please let me know if you're happy with this solution.
I'm not sure if anything is needed for nuget.org to accept a new package with the same prefix.

[vkhorikov]

Fantastic work, thanks @bothzoli . This is probably the longest standing unresolved request for this library.