Fix .NET Core and .NET 5 support #40
Conversation
This commit produces a package that works correctly for consumers using .NET Core and .NET 5. The project files are converted from legacy csproj to the newer SDK-style projects. These originated with .NET Core, but still allow targeting .NET Framework. In addition, this commit: - Removes the .nuspec file, specifying properties in .csproj files. - Moves common MSBuild properties to Directory.Build.props file. - Removes all post-build steps, and use reference items instead. - Correctly specifies the runtime library, without using a .targets file. - Removes the "binary" folder from the repo. - Adds several files as solution items, making them easier to edit in Visual Studio.
This helps editors enforce code style.
SourceLink allows a consumer of the package to step into this library's source code in Visual Studio. Deterministic builds allow a user to reproduce the exact same binary on their own machine to validate the that the binaries in the package were built as advertised.
|
@drewnoakes Thanks so much! I need a little time to learn the changes about this. I will merge it. |
|
@jingwood sure, no problem. Take your time. I wanted to use this in a .NET 5 application, and with the changes in this PR was able to do so using a local package file. So I am unblocked for now, though of course I'd rather use a public package. I'm happy to answer any questions you may have. |
|
@drewnoakes Thanks! The project config looks very cool and professional, it resolved my early questions such as how to package a native DLL. I am going to publish a new package with these latest changes. |
|
@jingwood I'm glad to hear the changes work for you. I don't think you need to create two packages. It is possible to support both platforms in a single NuGet package. We will need more changes here though. I'm curious to learn how to do that, so I'll take a look. |
|
Hmm, this seems more difficult than I hoped it would be. See:
It may be easier to produce two packages. |
|
@drewnoakes Thank you very much! I am trying to set a different package id like this #41 |
Fixes #38, follows #39.
This PR fixes creation of the package for .NET Core and .NET 5 users, maintaining .NET Framework support.
It converts the projects from legacy csproj to newer SDK-style projects, which enable several new features such as native multi-targeting and NuGet pack from the project without a .nuspec file.
In future, to create a new version of the package:
<Version>element inDirectory.Build.props. This controls the assembly and package version in a single place.D2DWinFormproject in VS (or viadotnet pack).I've also enabled deterministic builds and SourceLink. Consumers of the package can now step into the library's code, and Visual Studio will download the source from GitHub directly.
A second
.snupkgfile is created alongside the.nupkgfile, which will be uploaded to nuget.org automatically vianuget.exe push foo.nupkg. Users can download this when debug symbols are needed. The format of these symbols is portable across runtimes/frameworks.The package icon is now embedded in the
.nupkgfile, rather than downloaded from esyshub.st101.workers.dev.The package license is now an SPDX expression (
"MIT") rather than an embedded file.I added an .editorconfig to avoid breaking code conventions in the editor (i.e. accidentally converting leading tabs to spaces).
See individual commit messages for more details.