NuGet: Strong name signing

[xupefei]

Note: for support questions, please use stackoverflow. This repository's issues are reserved for feature requests and bug reports.

• **I'm submitting a ... **

  • bug report
  • feature request
  • support request or question => Please do not submit support request or questions here, see note at the top of this template.

• Do you want to request a feature or report a bug?
  Request a feature.

• What is the current behavior?
  The NuGet FFmpeg.AutoGen.dll is not strong-name signed.

• What is the expected behavior?
  The NuGet FFmpeg.AutoGen.dll is should be signed with a strong-name.

• What is the motivation / use case for changing the behavior?
  Strong-name-signed assembly is not able to load an unsigned assembly. If I sign it manually, I need to stop using the NuGet package and maintain a local copy by myself.

• Please tell us about your environment:

• version: 3.4

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

[Ruslan-B]

Please explain the motivation. I can make a good guess that you are using enterprise build environment if so will your sponsor strong-name-signed assembly package? Some one need to maintain the strong signed package any way.

[xupefei]

It is because a strong-name signed application is not able to load an unsigned one. When compiling, it says:

Surely lots of people complain that the strong-name is totally useless, however, in reality, it is necessary when you want to add something to GAC.

will your sponsor strong-name-signed assembly package

Are you talking about a code signature? A strong-name signature is something different, which is free and everyone can generate. It is also safe to put the key to GitHub since it really does not mean much and lots of open-source projects are uploading it.

[Ruslan-B]

I'm not going to debate on whether to strong name sign open source nuget libs:
octokit/octokit.net#405 (comment)
reactiveui/ReactiveUI#43 (comment)

So the pain it causes is real, just as the pain of not SN is real for others. This discussion is about which pain is better suffered and how many people will suffer that pain

• using SN and suffering assembly loading+binding redirect issues; or
• not using SN and forcing people to ILMerge/workaround

the only legitimate use of SN is when you have to load more than one version of the same library into an application. This almost exclusively happens with large applications that have plugin support, like Visual Studio.

I would suggest to look to tools like this:
https://brutaldev.com/post/net-assembly-strong-name-signer

[Ruslan-B]

Looking down these threads I see some people manage to resolve issues connected with strong name signing and looks like there are no extra cost involved.
I'll make another round of research.

[Ruslan-B]

Slightly off-topic but are seriously using GAC?

[xupefei]

Yes, I am currently experimenting with adding my WPF application to GAC to (hopefully) get some speed-up on loading (you know, WPF loading is slow as hell).

I see your link, that some projects are publishing two NuGet packages, one signed and another not. Can FFmpeg.AutoGen do the same?

Nevertheless, if you decide not signing with a strong-name, I can of course look at .NET Assembly Strong-Name Signer, which is not a complex work :)

[Ruslan-B]

Yep, it is know to me especially if you are using 3rd party components. Not sure GAC is going to help though.

I'm testing how the strong name is going to impact development process. So far travis build system is not okey with it but will see how problematic it is to fix.
I'll keep you posted.

[Ruslan-B]

@xupefei I've updated the nuget strong name signed assembly. If all good please close the issue.

[Ruslan-B]

So far you cannot sign the assembly using linux tool-chain and it also creates minor confusions in visual studio property showing it as delay sign only default state of checkbox. It does not bother me much.

[xupefei]

Thank you! I just got the version 3.4.0.3 from NuGet and it is now signed.

Just to mention, AppVeyor has a Windows 10 + VS2017 build environment which may be more friendly to a C# project.

[Ruslan-B]

Thank you. I'll take a look.