I updated a PCL with profile 259 to .NET Standard 1.0 and want to update the corresponding NuGet package accordingly. I changed the folder containing the actual DLL from portable-net45+win8+wp8+wpa81
to netstandard1.0
, but I am not quite sure how to structure the dependencies of the package.
If I use the .NET Core CLI to create a package (dotnet pack
), the dependencies section in the nuspec file simply looks like this:
<dependencies>
<group targetFramework="netstandard1.0">
<dependency id="NETStandard.Library" version="1.6.0" />
</group>
</dependencies>
However, when I install this package to a classic .NET 4.5 or PCL project that still uses packages.config, then this file gets "polluted" with all the dependencies from the NETStandard.Library
metapackage, like so:
- Shouldn't this be avoided? One way to do that is to create empty dependency groups in the nuspec file as suggested by Oren Novotny on the GitHub page of NuSpec.ReferenceGenerator. However, he himself discourages this in one of his recent blog posts.
- Should I target the whole NETStandard.Library metapackage or just the packages that I actually need? Wasn't the idea of .NET Standard / .NET Core being easily runnable on all platforms that support the dependencies of your package?
Unfortunately, the official documentation for NuGet packages with .NET Core / .NET Standard is not written yet.
I've had to address this problem for packages I maintain that target both .NET Core and .NET 4.5. The approach I use touches on both points of your question:
netstandard1.X
andnet45
. Initially, use theNETStandard.Library
metapackage to make targeting the former easy.NETStandard.Library
with references to the specific packages I actually need.In the first step, my project.json looks something like this:
Any dependencies that themselves are already compatible with either framework go in
dependencies
, while specific .NET Core or .NET 4.5 dependencies go in their respective sections as needed.With
dotnet pack
, this produces exactly what I need: a single.nupkg
that can be installed in either type of project and pulls in only what it needs for that framework.In the second step, I swapped out
NETStandard.Library
with the few packages I actually needed for .NET Core:This second step isn't necessary, but it's nice to produce a package with minimal dependencies for both platforms.
NETStandard.Library
is useful in the development phase, when you're not quite sure what you'll need to use in the core API.