Strongly sign assemblies, for nuget package

[sbohmig]

Hello, would it be possible to strongly sign the nuget package assembly?

[nkreipke]

See #108. Im still maintaining my fork at https://www.nuget.org/packages/Sprache.Signed/.

[jzabroski]

You can just use StrongNamer nuget package to do this for you

[sbohmig]

Thank you very much, John.

Great to see a signed version does exists, how could I miss it... That is exactly what I needed.

The StrongNamer is interesting although we only need to sign selected assemblies and this adds extra config work.

Thanks again!

[jzabroski]

@sbohmig I think you're misunderstanding strong naming. If you have to strong name one unsigned reference in a project, you have to sign them all, or the DLL context won't load them. That's why you add https://github.com/dsplaisted/strongnamer as a PackageReference to your "entry point" DLL/csproj and it automatically signs ALL of these packages for you.

Caveat lector, if signing a DLL for purposes of COM component for things like Office plug-ins, then you probably want a stable key or a sophisticated component upgrade process.

[sbohmig]

@jzabroski I believe I do understand. Sprache is the only unsigned assembly we need to upgrade. Replacing it with a signed version is the least effort, has zero impact on build processes and does not introduce more dependencies.

I only briefly looked at StrongNamer. I really like the idea but saw issues listed that would require spending us more time to evaluate: Debugging signed assemblies to mention one. The repository does not seem to be maintained since 2 years and issues remain unanswered. This makes any adoption a more lengthy process on our end. Using the "al" tool directly is an option too.

[jzabroski]

Understood - extra dependencies can cause increased time to solve problems. I'm mainly championing the approach because I think OSS devs should get out of the business of supporting strong naming altogether.

[denwanke]

@jzabroski We use strong naming in our solutions to prevent tampering with sensible code parts like license checks. We'd love to use the "official" NuGet package but unfortunately we cannot. Using StrongNamer is not a real option to consider, it causes some troubles, especially in CI Builds. Why do you against signing your code to enable more users of your library? What is so bad with it? It does no harm... And BTW, Sprache is the only unsigned library we came across over the years. Pretty weird...