Open duszynski opened 9 years ago
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?
Security reasons. I was trying to use it in healthcare project, but app must be signed.
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:
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).
Can you update nuget packages with signed versions?