Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider strong-naming with published SNK #68

Open
TetsujinOni opened this issue Jan 12, 2018 · 2 comments
Open

Consider strong-naming with published SNK #68

TetsujinOni opened this issue Jan 12, 2018 · 2 comments

Comments

@TetsujinOni
Copy link

To allow organizations which require strong-named assemblies so they can use code-signing for their internal projects to consume Pri.LongPath, consider strong-naming the package.

@SchreinerK
Copy link
Contributor

SchreinerK commented Jan 28, 2018

@TetsujinOni IMHO organizations should build binaries with own key if this is requiered.
But I am with you, there could be also an alternate NuGet package with a strong name.

@TetsujinOni
Copy link
Author

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies was the source of my suggested path of using a published SNK for signing the open source library, to enable the local build reference compatibility with the nuget package.

Which is, of course, why StrongNameSigner and local signing are less desirable solutions than opening an upstream project issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants