Reputation: 1618
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
Upvotes: 2
Views: 1105
Reputation: 14981
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.
Upvotes: 2