Versions not resolving for Nuget packages

Question

I am receiving a warning (which is treated as an error on my project) for an in-house developed Nuget package. I am not sure what I am doing wrong- according to the documentation, 1.0.0.13 >= 1.0.0 should resolve.

The warning/error I am receiving:

NU1603 MyPackage.Services 1.0.0.13 depends on MyPackage.Base (>= 1.0.0) but MyPackage.Base 1.0.0 was not found. An approximate best match of MyPackage.Base 1.0.0.13 was resolved.

MyPackage.Services.nuspec:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>MyPackage.Services</id>
    <version>1.0.0</version>
    <authors>Me</authors>
    <owners>Me</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>My Package Description</description>
    <copyright>Me - 2018</copyright>
    <dependencies>
      <dependency id="MyPackage.Base" version="1.0.0" />
      <!-- ... -->
    </dependencies>
  </metadata>
</package>

Thanks

It is resolving, it's telling you that it used 1.0.0.13 because the exact version requested (1.0.0, which in this case is a transitive dependency) could not be found. NU1603 is a warning by default, not an error. Treating it as an error is breaking your own build on purpose. Since you control MyPackage.Services, you can change its depdency on MyPackage.Base to a version that actually exists (1.0.0.13), and the warning should disappear. — zivkan, Nov 27 '18 at 23:05
@Stefan, Thanks for the thought. I tried that, but have the same issue. — AndrewP, Nov 27 '18 at 23:11
@Ziv, that is in line with what I thought would be the case. it would be nice if it didn't throw a warning when it's behaving as expected, but perhaps I will just have to supress NU1603 warnings. If you want to write that as an answer, I am happy to accept it. — AndrewP, Nov 27 '18 at 23:11
In many cases, you may want a warning as developer if e.g. a package was removed from NuGet and your build suddenly changed. There is also a linup file feature that allows this to fail builds if a previously resolved version is no longer downloadable / available on feeds. — Martin Ullrich, Nov 29 '18 at 14:20
If you're using `PackageReference`, you should be able to set `NoWarn="NU1603"` on the `` item or add it to the `` property in your project file. — Martin Ullrich, Nov 29 '18 at 14:21
@MartinUllrich ~ I tried adding `NoWarn` as both an attribute and an element, but the warning persists nonetheless. This is a newly created WPF project using `PackageReference`. Any ideas? — InteXX, Feb 10 '19 at 03:37

score 2 · Accepted Answer · answered Nov 30 '18 at 15:29

As the warning message says

An approximate best match of MyPackage.Base 1.0.0.13 was resolved.

So it was resolved. However, by opting in to treating warning as errors, you asked it to break your build.

Since you own MyPackage.Services, you can change its dependency on MyPackage.Base to a version that actually exists to stop getting this warning. Other options are to stop treating NU1603 as a warning, or possibly suppressing it completely.

As Martin Ullrich said in the question's comments, there are scenarios where developers do care that different versions were restored than they expected. In fact, it was so important to some customers that a new feature was recently added to improve the security of restoring packages (see recent npm event-stream issue). This makes NuGet warning NU1603 much less useful, but it's existed for far longer than package locking.

Versions not resolving for Nuget packages

1 Answers1