Installing a netstandard2.0 Nuget Package inside a different netstandard2.0 library NU1202

Question

I'm currently struggling with something that seems like it's simple, but I can't track down anyone with a similar issue.

I'm converting some libraries to netStandard and one depends on another. We'll call them A and B.

A is compiling fine as a netStandard2.0 library, built with the 3.1 SDK according to dotnet --version in the directory. The nupkg is built in the Release folder and I move it to a local package source to test on my box.

B is a netStandard2.0 class library as well. It requires A, but navigating to my nupkg for A inside of NuGet Package Manager for B and clicking install generates a curious error.

NU1202 A is not compatible with netStandard2.0, Package A supports: netcoreapp2.1

A is a netStandard library. B is a netStandard library.

When I look at the A.csproj file in the tag I'm seeing:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <Description>The initial .net standard 2.0 offering of A</Description>
  </PropertyGroup>
</Project>

So it seems to be targeting for a netStandard2.0 (which includes netFramework 4.6.1 to netCore 2.2?)

Am I missing something simple?

After googling around with nu1202 and netStandard2.0 - which mostly came up with a scenario of A being a library and B being an application, not a B being a library like my situation - I present:

Things I've Tried Based on Dissimilar Problems

1. Confirm the dotnet --version of each of the A / B projects, both at 3.1.402
2. Confirmed my Nuget Package Mangaer version is fairly recent / up to date: 5.7.0
3. Attempted to use the Package Manager Console to the exact same result.
4. Cleaned and Rebuilt / Packed the A.csproj
5. Tried including the A.nuspec file in the Package Source folder with A.nupkg
6. Pulled the A.csproj manually into the project to confirm it could be added as a Project Reference which worked, but isn't how I want to solve this problem.

I've maybe tried more but at this point, maybe the question I should be asking is: Is it possible to reference netStandard libraries inside of other netStandard libraries?

What am I missing?

Answer 1

I believe, in the end, that this might be an issue with the Pack/Build (with Generate Package on Build) functionality in VS.

I am able to manually create the package of the A library inside of Nuget Package Explorer, that package will import into B just fine.

I followed this resource , but was never able to build the package using Visual Studio, which makes it difficult to modify the version of Nuget Package Manger nowadays since it's bundled in. I'm at version 5.7, it may be that 5.6 would work as that's listed as the latest Stable release on google, but either way - for now, I believe I'll just manually make my packages instead of trying to auto-generate them.

If anyone has a better solution or thoughts about how to troubleshoot this, I am all ears.

---

EDIT

---

It turns out, the auto package build feature DOES work.

What happened in the end: I commandeered some old .net Core library titles, to downshift them to .net Standard instead of keeping 2 parallel copies.

There was already a .net core version of A.1.0.0.nupkg and a B.1.0.1.nupkg, but in a different nuget package source.

When I build a NEW .net Standard A.1.0.0.nupkg and put it in a local source, somehow even when pointing to that local source, nuget tried to install the .net core from ... i guess a cached copy of the production nuget package source (I cleared caches like 50 times so I don't know how nuget is getting these wires crossed).

Easily replicatable by making a version .net Standard A.1.0.1.nupkg, it imports fine because there was no .net core A.1.0.1.nupkg. You can then rename that package and reversion it in Nuget Package Explorer, but not change the contents, and it will fail. This was confirmed when I had to stair step my versioning of the .net Standard version of B.nupkg from 1.0.0 to 1.0.2 thus going further than the .net Core version of B.nupkg.

So in the end, the auto package functionality isn't broken (thankfully). The Nuget Package Explorer manual creation fixed my problem because I ticked up the version when I manually made it.

I would never have expected the production library package source to interfere with a local package folder...