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

Figure out NuGet packaging with netstandard #99

Closed
masojus opened this issue Jul 28, 2017 · 4 comments
Closed

Figure out NuGet packaging with netstandard #99

masojus opened this issue Jul 28, 2017 · 4 comments
Assignees

Comments

@masojus
Copy link
Contributor

masojus commented Jul 28, 2017

At a minimum we need to make sure the NuGet package has the new binary, and probably won't have some or all of the old binaries.

However, there's also the question of using the new PackageReference and NuGet properties that can be described in the .csproj file and the latest versions of NuGet (4+). For example, you can put most or all of the .nuspec in the project file now, but there are caveats.

What happens if we're using <PackageReference> but a consumer tries to use a NuGet v2.x to download our package? What about substitution of variables--right now we pass in a substitution for the $version$ on the command line when we execute nuget.exe.

@masojus masojus self-assigned this Jul 28, 2017
@masojus
Copy link
Contributor Author

masojus commented Sep 25, 2017

@masojus
Copy link
Contributor Author

masojus commented Oct 20, 2017

With PR #125 this is mostly done, but we're still building two NuGet packages: the old one with .nuspec and the PCL/.NET 4.5/.NET 3.5 artifacts in it, and the new one with the multi-targeted netstandard2.0+netfx45 projects using .csproj-based NuGet specification. Once we flip the switch and only build/publish the new stuff, this is done.

@masojus
Copy link
Contributor Author

masojus commented Nov 5, 2017

We should solve the naming issue when we flip the switch too--the .NET 4.5 binary built by the multi-targeted .csproj has the name Keen.NetStandard.dll due to the project name, which is strange. This is also called out in Issue #73.

@masojus
Copy link
Contributor Author

masojus commented Nov 14, 2017

Renaming the dll is fixed in PR #136 with commit 55b8985, so this is complete.

@masojus masojus closed this as completed Nov 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant