Giters

etishor / Metrics.NET

The Metrics.NET library provides a way of instrumenting applications with custom metrics (timers, histograms, counters etc) that can be reported in various ways and can provide insights on what is happening inside a running application.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Nuget packages with strong names

duszynski opened this issue · comments

commented

Can you update nuget packages with signed versions?

commented

I have not used strong named assemblies in the last years. I'm not against them, but I know they are known to cause trouble. I'll take a look on how popular projects handle this and see if it is possible. The core library has (and will never have) any 3rd party external dependencies - so it should be easy to have it signed. Adapters on the other hand have dependencies which are probably not signed (like Nancy).

Can you provide more details on how strong named packages would be helpful?

commented

Security reasons.
I was trying to use it in healthcare project, but app must be signed.

commented

Here is a link to the strong naming policy and reasons for the .net corefx libraries. The general idea is to sign core framework libraries for compatibility and not to sign open source, general purpose libraries to avoid issues with dependencies and to have the "drop-in" replacement possibility.

Strong naming does not give you any security. It gives you guarantees of identity of the signed assembly.

That being said I see two options:

  1. publish a .nuget package under a different name (Metrics.NET-Signed) with a signed version of the library with the key included in the repository for posterity.
  2. sign the assembly yourself using something like Nivot.StrongNaming - an example with signing NancyFX here.

Since I personally don't use strong naming and don't foresee ever using it, I don't want to take responsibility of maintaining a strong named package - but it should be easy for anyone to clone the repo and publish the signed package.

I would recommend using option 2 because of the benefit of being able to sign it with your own key (thus getting some "security" as the assembly can't be replaced).