Strong named nuget version

[Muarl]

Hey there, could you provide strong named nuget?
We could need it ;)

[MikeVensel]

I have run into this kind of issue several times with other libraries and the easiest solution for me has been to just use the StrongNamer nuget package which can be found here. All you have to do to implement it is add the nuget package to your project and build.

[jzabroski]

@MikeVensel Wouldn't it be great if the new .net core Common Project System let you just write:

  <PackageReference Include="AsyncEx" Version="2.0.0" StrongName="Auto" />

[jzabroski]

@MikeVensel Actually... Check out:https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Which in turn links to: https://docs.microsoft.com/en-us/nuget/create-packages/sign-a-package

which says:

Requires nuget.exe 4.6.0 or later. dotnet.exe support is coming soon - #7939

...There is also <PublicSign>true</PublicSign> and a FakeSign nuget package from 2015.

from: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/public-signing.md

I'm a little confused as to what the relationship is between StrongNamer and FakeSign AND WHY IS THIS SO CRAZILY OBFUSCATED MICROSOFT. lol

[jzabroski]

@MikeVensel Well, this brought me down a rabbit hole on a Friday afternoon.

1. FakeSign is more or less obsolete; I submitted a PR to CoreFX to fix the documentation.
2. <PublicSign>true</PublicSign> is the way to go for NEW greenfield projects
3. StrongNamer is the way to go for compatibility with open source projects; Jared Parsons said on twitter that he isn't convinced of the utility of making this widely accessible. LOLOLOL.
4. Microsoft.CodeAnalysis.DesktopStrongNameProvider inside the Roslyn SDK appears to be the officially supported way from Microsoft, but it isn't packaged as an MSBuild target or something generally consumable by the public. It appears this is what /publicsign internally leverages; ideally, StrongNamer would also leverage the same API

Sigh. Microsoft never makes things relentlessly easy.

[MikeVensel]

@jzabroski Oof what a way to spend a Friday. I appreciate you putting all this information together though. Signing using public keys seems like a great thing for open source projects so hopefully developers creating new products will start to move in that direction.

[StephenCleary]

Short answer: no, I have no plans to add strong-naming to AsyncEx now, for reasons described here. See also #2.

A Short History of Strong Naming in AsyncEx:

• AsyncEx v2 was strong named. Endless problems ensued and only grew as the library's popularity grew. The strong naming was removed in v3.
• AsyncEx v4 had a separate library that was strong named. More problems ensued to the point it became a maintenance burden. This strong named option was also removed.
• AsyncEx v5 (prerelease) was public signed for a release or two. I had high hopes that public signing would work around the problems with strong naming, but it did not fix all the problems with strong naming, so the public signing was also removed.

I still think the .NET ecosystem would be better served by a service that auto-signs packages following a semantic versioning approach. So far, I have not had time to write this service.

[jzabroski]

@StephenCleary how is that service idea you have different from StrongNamer?

[StephenCleary]

What I'd like to see is a web service of sorts where you (or anyone) can submit a NuGet package id. This web service watches for new versions of NuGet packages matching any of the ids it monitors and:

1. Downloads the package,
2. Strong names it (essentially how StrongNamer works),
3. Publishes it to NuGet as a new package, something like "AutoStrongNamed.Original.Package.Name".

All the pieces for this (monitoring, downloading, StrongNamer, publishing) are solved problems. Someone just needs to put it all together and host it somewhere.

[jzabroski]

Got it. I'm in agreement. I'm sussing out what the nuances are between StrongNamer using Mono.Cecil and Roslyn SDK's Microsoft.CodeAnalysis.DesktopStrongNameProvider. I think once I wrap my brain around that I might take this on.

…

On Fri, Oct 25, 2019, 9:11 PM Stephen Cleary ***@***.***> wrote: What I'd like to see is a web service of sorts where you (or anyone) can submit a NuGet package id. This web service watches for new versions of NuGet packages matching any of the ids it monitors and: 1. Downloads the package, 2. Strong names it (essentially how StrongNamer works), 3. Publishes it to NuGet as a new package, something like " AutoStrongNamed.Original.Package.Name". All the pieces for this (monitoring, downloading, StrongNamer, publishing) are solved problems. Someone just needs to put it all together and host it somewhere. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#196?email_source=notifications&email_token=AADNH7OUK6GSJTHTIUJBKGLQQOKLHA5CNFSM4JDPO65KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECJ4IYQ#issuecomment-546554978>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADNH7IY7N2X7OHHDKV7AMDQQOKLHANCNFSM4JDPO65A> .

[Muarl]

Thanks for the very detailed answers. Especially as you had to answer them again. Sorry for that.