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

Public sign assemblies #85

Merged
merged 4 commits into from Aug 2, 2022
Merged

Conversation

drewnoakes
Copy link
Collaborator

This enables public signing for the assemblies in the package.

From that document:

Developers use public sign for open-source projects.

This enables other strong-named assemblies to utilise this library.


It also bumps the copyright year and version. @jingwood if you're happy with this, could we get a package out? I'm blocked on needing strong naming for a project I want to use this in. Thanks! Alternatively you can give me publish permissions. My NuGet user ID is 'drewnoakes'.

This enables [public signing](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/security#publicsign) for the assemblies in the package.

From that document:

> Developers use public sign for open-source projects.

This enables other strong-named assemblies to utilise this library.
@jingwood
Copy link
Owner

jingwood commented Aug 2, 2022

resolves the issue #84

@jingwood
Copy link
Owner

jingwood commented Aug 2, 2022

@drewnoakes Thank you very much! I have invited you as the collaborator of the repository and NuGet package. Thanks all the contributions to this library so far.

@jingwood jingwood merged commit 696b278 into jingwood:master Aug 2, 2022
@jingwood
Copy link
Owner

jingwood commented Aug 2, 2022

@drewnoakes Do you think it would be safe if we migrate to .NET 6 before building the next package? #86

@drewnoakes drewnoakes deleted the strong-naming branch August 3, 2022 10:31
@drewnoakes
Copy link
Collaborator Author

I have invited you as the collaborator of the repository and NuGet package.

Thanks! One question I have is whether you have a special process to produce the NuGet package, or whether you just pack the WinForms project.

Do you think it would be safe if we migrate to .NET 6 before building the next package? #86

What would be the reason to migrate to .NET 6? I think it makes sense to update if you want to take advantage of features in that runtime or framework, but it does mean that users of .NET 5 would be left behind.

@jingwood
Copy link
Owner

jingwood commented Aug 7, 2022

@drewnoakes

or whether you just pack the WinForms project.

Just pack the WinForms project. Pack two packages for each x86 and x64 platforms.
image

What would be the reason to migrate to .NET 6? I think it makes sense to update if you want to take advantage of features in that runtime or framework, but it does mean that users of .NET 5 would be left behind.

Since the .NET 4.0 seems no longer supported and cannot be compile in VS2022, so I think whether or not to choose a LTS version like .NET 6.0, but thanks for your review, I have understand the difference.

@drewnoakes
Copy link
Collaborator Author

Since the .NET 4.0 seems no longer supported and cannot be compile in VS2022

I can build in VS2022. I probably have a targeting pack installed. I think we can add one via PackageReference if needed, to ensure everyone can build this repo locally.

@drewnoakes
Copy link
Collaborator Author

The targeting pack NuGet package is Microsoft.NETFramework.ReferenceAssemblies. it should be added with PrivateAssets="All".

@jingwood
Copy link
Owner

jingwood commented Aug 7, 2022

Thanks. Saw this after release a new NuGet package, the new version 1.4 available now. I will try it in the next build.

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

Successfully merging this pull request may close these issues.

None yet

2 participants