Strong named assembly

[tongbong]

One of our client only integrate strong named assemblies...
https://msdn.microsoft.com/en-us/library/wd40t7ad%28v=vs.110%29.aspx

It seams easy to do:
https://msdn.microsoft.com/en-us/library/xc31ft41%28v=vs.110%29.aspx

Any thought about this?

[angularsen]

I don't have any experience with that, but know what it is about and open to the idea.
I recall some pain points discussed about nuget and strong naming a long time ago, but I don't recall exactly what it was all about. Something about assembly versioning is the only thing that comes to mind.

[angularsen]

FYI. I am away all this week and will not be able to follow up before next week.

[angularsen]

Do you want to pursue this and add a PR? I don't have much time to put into this project these days unfortunately.

[angularsen]

As I thought, there is a lot of debate on whether to strong name sign open source nuget libs.

octokit/octokit.net#405 (comment)
reactiveui/ReactiveUI#43 (comment)

Based on these, I am inclined to NOT sign Units.NET. Open to discuss, naturally.

I understand your hesitancy in strong-naming, but what has me quite confused is that it appears you have a certificate in each of the source projects, and are essentially strong-naming the source, but not the NuGet package. I would think this should be done the other way around: don't strong-name the source, so that other developers can build without having the certificate problems, but strong-name the NuGet package so that those who don't need to compile the source can simply use the NuGet package in their own strongly named solutions.

Oops - ignore that cryptic reference to how you've already strongly named the source. I was looking at my fork.

Still, the point remains. I agree - don't sign the source. However, please sign the NuGet so that people can use it without having to compile it. :-)

[angularsen]

@bplett I'm not sure I follow. what do you mean by signing the nuget but not signing the projects?

Is this what you are referring to?
https://github.com/aspnet/Signing/blob/dev/Spec.md

[WGVDNSoftware]

I think the subject has been discussed enough in the threads you mention. I just happen to be on the side that would like to see the NuGet packages signed. I believe the biggest reason for not signing the projects is because of the hassle when people are working with the source and compiling it themselves. I'm suggesting that you could just sign the NuGet packages when you publish them and that would solve the problem for all the people who want to use the NuGet package even with strong naming in place. The way it is now, I want to use the NuGet package but can't. I have to keep a copy of the source and recompile it JUST to get the strong-naming in place.

[angularsen]

@WGVDNSoftware I absolutely get your point of view, but from what I've read of the discussions there seems to be a consensus in open source to not do strong name signing - even if it is trivial to do so. I can only refer to the discussions for the arguments, as I do not really have any experience with this myself.

[JohnCaruthers]

@anjdreas I am in a similar situation to WGVDVSoftware. I must respectfully disagree with the conclusion that you came to regarding strong naming open source projects, the information is dated. I have successfully deployed strong named open source projects, without compromising the key file. I have a great deal of experience in this arena, and I am willing to give you a detailed explanation by email, voice, and even team with you to get this done.

It really would be GREAT if we could use the NuGets directly rather than signing our own just for the sake of strong-naming. :-)

Btw, it would also give us more incentive to contribute to the project rather than just keep our own changes since we have to keep a local copy anyway.

[angularsen]

@jecaruthersjr I am all ears, please put forward your arguments and also please explain why the debate in the links are outdated.

I don't have any experience with consuming or creating strongly signed libs, nuget or otherwise. But I did link to quite extensive debates on repos of largely popular nugets, and the consensus at that time seemed clearly towards not strong naming the open source nugets. My conclusion was solely based on their conclusion as I did not have any new info to add to the conversation.