Do not warn when NuGet resolves to a higher version of the package unless its change in major version

[anangaur]

Today NuGet warns with NU1603 if the package resolved is not the min version specified. E.g.

This looks like information to many users. Following 2 options may be desired:

1. Warn only if resolved Major version is different than the specified min Major version. i.e. Do not warn for 4.0.1 -> 4.10 but warn for 4.0.1->5.x

2. Have an option to convert this warning to information message from settings

[emgarten]

The screenshot shows NU1603 for Castle.Core 4.0.0, the issue here is a package authoring here which has since been fixed: castleproject/Core#239

NU1603 refers to missing packages, not the resolved version in the final flattened graph. This warning appears when the min version of a dependency cannot be found. Finding a version of a higher patch does not help here, the expected exact match is still missing.

From https://docs.microsoft.com/en-us/nuget/reference/errors-and-warnings for more details on this warning.

A package dependency specified a version that could not be found. A higher version was used instead, which differs from what the package was authored against.

This means that restore did not find the best match. Each restore will float downwards trying to find a lower version that can be used. This means that restore goes online to check all sources each time instead of using the packages that already exist in the user package folder.

[xlegalles]

You say "differs from what the package was authored against" but what about this one:

warning NU1603: KAutomate.Inf.RESTGateway_UT depends on Newtonsoft.Json (>=
10.0.2) but Newtonsoft.Json 10.0.2 was not found. An approximate best match of Newtonsoft.Json 10.0.3 was resolved.

I have specified >= 10.0.2 and did not constraint the version to =10.0.2 so to my opinion, this warning is wrong.
Actually, we have hundreds of NU1603 warnings and while I would like to keep an eye on several ones where a major version upgrade has been resolved, I don't want to keep all others (x100) where a simple minor upgrade has been applied. It is not maintainable because these warnings are displayed during the restore, the build, the packaging and the publishing: the build server log is so huge that it is just not readable.

Another example:

warning NU1603: log4net 2.0.8 depends on System.Diagnostics.
StackTrace (>= 4.0.1) but System.Diagnostics.StackTrace 4.0.1 was not found. An approximate best match of System.Diagnostics.StackTrace 4.3.0 was resolved

While this one is "interesting":

warning NU1603: Microsoft.TestPlatform.TestHost 15.3.0 depen
ds on Microsoft.Extensions.DependencyModel (>= 1.0.3) but Microsoft.Extensions.DependencyModel 1.0.3 was not found. An approximate best match of Microsoft.Extensions.Depende
ncyModel 2.0.0 was resolved.

[emgarten]

Here is an example of how NU1603 can happen:

1. Create packages B 1.0.0 and B 1.0.1
2. Create package A 1.0.0 that depends on B >= 1.0.0
3. Install A 1.0.0 into a project
4. NU1603 does not occur because B 1.0.0 exists
5. Delete B 1.0.0 from the package source
6. NU1603 now occurs because A 1.0.0 would try B 1.0.0 as a best match, but since B 1.0.0 does not exist it cannot be considered. The package sources forced the resolver to select a higher version of B.

Here is an example where NU1603 does not occur:

1. Create packages B 1.0.0 and B 1.0.1
2. Create package A 1.0.0 that depends on B >= 1.0.0
3. Install A 1.0.0 into a project
4. Install B 1.0.1 into the project top level so that B 1.0.1 is used over 1.0.0
5. The project uses A 1.0.0 and B 1.0.1
6. NU1603 is not displayed since B 1.0.0 was found, considered, and then rejected by the resolver.

NU1603 is useful for the following reasons:

• Repeatable builds, in the first example if B 1.0.0 shows up in the sources later it will be considered, which could change the build.
• Performance, when the lowest match is missing restore will try each time to find a lower version on the sources. This behavior is the same as if a version had a *, and this will decrease restore performance.

NU1603 is not intended to cover these scenarios:

• Compatibility based version range constraints
• Semantic Versioning

NU1603 as an error

I recommend treating NU1603 as an error to ensure that restores are fast and consistent.

<WarningsAsErrors>NU1603</WarningsAsErrors>

[davidfowl]

Echoing what @emgarten said:

@xlegalles The minimum version of the package should be what actually built against. You shouldn't be making nuget packages that target an arbitrary minimum that doesn't exist. That leads to inefficiencies where you're forcing consumers to do a feed check to find the best match when that could be skipped.

With the new coupling of producing and consuming packages, it makes it really hard to mess this up since there's no separate nuspec being authored.

[emgarten]

Actually, we have hundreds of NU1603 warnings and while I would like to keep an eye on several ones where a major version upgrade has been resolved, I don't want to keep all others (x100) where a simple minor upgrade has been applied.

@xlegalles this sounds like a new feature, unrelated to NU1603. I suggest opening a new issue to track it and explain what you would like to see in the warnings/log. It sounds useful.

[davidfowl]

@xlegalles why do you have so many warnings?

[xlegalles]

@davidfowl Sorry, I did not see your question: well, we are migrating a big project to .NET Core and we have to manage quite a number of 3pp dependencies. Not all of them are already migrated but they are still compatible and everything work well. So this is the first cause of warnings: using .NET FW libraries from .NET Core.
Then, time to time we look after all of them and update versions which were quite all in beta/preview. But of course it happens in complete disorder. This is the second reason of warnings, the one I described earlier.
Note that we use a private Nuget repository: this is why we do the update manually and also why the resolution does not find exactly what it looks for.
Things are getting better with time because everybody migrates to .NET Core and the global picture is getting more consistent i.e. 3rd dependencies become the same across all libraries.

[Yuck]

This is broken, IMO. Please see the following warning details:

Dapper.SimpleCRUD 2.2.0 depends on Dapper (>= 2.0.0) but Dapper 2.0.0 was not found. An approximate best match of Dapper 2.0.4 was resolved.

The message itself appears to indicate that Dapper.SimpleCRUD needs Dapper that is version 2.0.0 - or greater. And in fact, Dapper 2.0.4 (which is greater...) is used as a resolution to this dependency.

How can any rational person see this as a valid warning and not the defective behavior that it is?

[davidfowl]

@Yuck not sure what you mean, why does Dapper.SimpleCRUD depend on Dapper 2.0.0:

It doesn't exist, the package is broken and should depend on a real version of Dapper, the one it compiled and tested against.

[nzbart]

I feel like there's a real disconnect here between how the NuGet developers like @davidfowl view the ranged version specification working vs. how some users, such as myself, think this should work. In @Yuck's example above, the warning seems nonsensical to some of us because the package said that it will function correctly with any version greater than or equal to 2.0.0 - whether that be 2.0.0 or 2.0.1. It doesn't matter that 2.0.0 doesn't exist, because 2.0.1 will do just fine. Why would the package manager warn when this constraint is satisfied?

It seems to me that @davidfowl is saying there's an implication that the original developer of the package must have built and tested their product against the exact version at the bottom of the range - in this case 2.0.0. Any movement from that exact version is allowed, but it's considered to be worth warning about because it wasn't the exact version tested against.

Maybe the warning could be reworded to make it clear for those of us who assume that any version that satisfies the constraint is fine?

[watfordgnf]

I missed the solution in here. The situation I'm in is that multiple old packages need Foo Package version 3.X.X but we have others that need Foo Package version 4.X.X. Our private feed only carries 4.X.X. Binding redirects are generated.

Is the issue that if we listed 3.X.X in our private feed then we would get both versions installed? I guess I'm missing how we can take action based on this warning, and what that action would be.

(this is an old Web Forms project being moved to PackageReference to deal with issues surrounding "netstandard" and 4.7.2)

[davidfowl]

No both versions wouldn’t be installed. The question is what was Foo built and tested with and why is that version not available?

[watfordgnf]

I guess my question is why would they say >=3.X.X if they meant =3.X.X. I guess I miss the utility of >= if you're not supposed to take anything that isn't strictly equal. (and in our case we only ever have one version of a package in our private feeds, for exact configuration control)

[davidfowl]

While that's 100% reasonable statement, the reality is that 98% of the time, the feed would have both versions. In the other 2% of cases:

• It was an error on the package author's behalf. They made a mistake authoring and put a random version in there that doesn't exist on any feed.
• The package consumer made a special feed with just the specific versions they needed.
• Something else I don't understand.

[mrubinstein]

We fall under the second use case - we keep only the latest version of our packages in the feed. NU1603 is something that we have to work around, quite frustrating.

[aolszowka]

@davidfowl We are encountering this with the Microsoft SQL Server Reporting Services (SSRS Team) Provided Package "Microsoft.ReportingServices.ReportViewerControl.Winforms" (https://www.nuget.org/packages/Microsoft.ReportingServices.ReportViewerControl.Winforms/)

According to your statements above this indicates that Microsoft's Reporting Team has a defect in their package creation process, this is because there is no such version as 14.0.0 Microsoft.SqlServer.Types (https://www.nuget.org/packages/Microsoft.SqlServer.Types/).

They seem to have the same impression that many of the developers are posting here, that >=14.0.0 should allow you to to consume any SemVer of 14.x.x

To assist in reporting this defect to Microsoft's SSRS Team (and for the benefit of the rest of us playing along at home): What is the "correct" way to indicate this behavior in NuGet?

Based on your comments above what I am seeing is that, in your world, >= should NEVER be used if that version does not exist as it is as good as putting = to a specific version resulting in NU1603, and if that version does not exist you are guaranteed to get a warning.

If I understood what you are trying to say, your claim is that in order to fix this defect in Microsoft SSRS Team's NuGet package that they should have declared their dependency is >=14.0.314.76 (which is a valid version), then when 14.0.1016.290 rolled around if a package had >=14.0.1016.290 this would have automatically upgraded without issue.

If that really is the case then why hasn't someone written a tool to go scan NuGet.org to find invalid package configurations and start sending out automated emails? Starting at home sounds like a great place to be.

In addition can you please kindly point to where in docs.microsoft.com this is explicitly documented to never target a non-existent version? What happens when the package has to be de-listed for security purposes? Otherwise you've broken people who would have worked without issue.

Here's a Git Repository that shows a simple reproduction of this defective packaging using only the Microsoft SSRS Team supplied NuGet packages: https://github.com/aolszowka/NU1603InSSRS

Realize that if you convert warnings to errors in this project your CI will fail due to this failure; it sure doesn't feel real good to suppress NU1603 but that is probably where we are at.

[abkonsta]

my nuget NLog.Extensions.RabbitMQ has the following in the nuspec

<dependency id="Newtonsoft.Json" version="12.*" />

However I am seeing this message:

warning NU1603: NLog.Extensions.RabbitMQ 2.7.6 depends on Newtonsoft.Json (>= 12.0.0) 
but Newtonsoft.Json 12.0.0 was not found. 
An approximate best match of Newtonsoft.Json 12.0.1 was resolved.

I see that a few people above have reported a similar issue. Why this this a warning if 12.0.1 perfectly matches 12.* ?

[davidfowl]

Your NuGet package should have floated to get a specific version then that version should have beeen burnt into the nuspec. Don’t put floating versions in the nuspec because it doesn’t mean anything

[nzbart]

@davidfowl I don't recall encountering this problem in any of the other package managers that I've used for various languages. So long as there is a package available that fits within the specified version range, other package managers are happy.

Is NuGet unique in having this restriction/philosophy? Why?

[davidfowl]

NuGet doesn’t work like lots of other package managers (though it does like the java ones). You may bee familiar npm which prefers the highest version of a dependency by default and it’s up tothe package author to clamp versions down. Works fine for dynamic languages where everything is a runtime breaking change, not so great in a statically types ecosystem which needs binary compatibility to function.

NuGet doesn’t float dependencies by default and prefers the lowest version of your dependency (the one you specified). That comes with a different set of trade offs of course but it’s also what lead to this behavior of “specify in the nuspec what you tested against” because as a package author and let the package manager resolve the correct version based on policy. This also leaves the package graph stable at install time.

I don’t disagree that these policies might change in the future as we default to more lock file specific experiences but until that switch happens., I’d recommend package authors specify the version they tested their package against.

[argium]

I treat warnings as errors on release builds to enforce compliance with Roslyn rules. I don't know why my build should be blocked by this warning.

Microsoft.Azure.WebJobs.Extensions 3.0.5 depends on Microsoft.Azure.WebJobs.Host.Storage (>= 3.0.11) but Microsoft.Azure.WebJobs.Host.Storage 3.0.11 was not found. An approximate best match of Microsoft.Azure.WebJobs.Host.Storage 3.0.13 was resolved.

The package it chose is totally reasonable...

[MaceWindu]

What I found interesting, is that half of examples here reference packages from Microsoft itself.
Here another one:
NU1603: Microsoft.ServiceHub.Framework 2.3.56 depends on StreamJsonRpc (>= 2.3.81) but StreamJsonRpc 2.3.81 was not found. An approximate best match of StreamJsonRpc 2.3.99 was resolved.

Edit
New version of required package gives even more errors

NU1603: Microsoft.VisualStudio.Telemetry 16.3.58 depends on Microsoft.VisualStudio.RemoteControl (>= 16.3.4) but Microsoft.VisualStudio.RemoteControl 16.3.4 was not found. An approximate best match of Microsoft.VisualStudio.RemoteControl 16.3.23 was resolved.
NU1603: Microsoft.ServiceHub.Client 2.4.227 depends on Microsoft.VisualStudio.Telemetry (>= 16.3.36) but Microsoft.VisualStudio.Telemetry 16.3.36 was not found. An approximate best match of Microsoft.VisualStudio.Telemetry 16.3.58 was resolved.
NU1603: Microsoft.VisualStudio.RemoteControl 16.3.23 depends on Microsoft.VisualStudio.Utilities.Internal (>= 16.3.5) but Microsoft.VisualStudio.Utilities.Internal 16.3.5 was not found. An approximate best match of Microsoft.VisualStudio.Utilities.Internal 16.3.23 was resolved.
NU1603: Microsoft.ServiceHub.Client 2.4.227 depends on StreamJsonRpc (>= 2.4.34) but StreamJsonRpc 2.4.34 was not found. An approximate best match of StreamJsonRpc 2.4.48 was resolved.
NU1603: Microsoft.ServiceHub.Framework 2.4.227 depends on StreamJsonRpc (>= 2.4.34) but StreamJsonRpc 2.4.34 was not found. An approximate best match of StreamJsonRpc 2.4.48 was resolved.

Microsoft guys should first adhere their own guides I think before pushing them to everyone...

[ardalis]

Still running into this with .NET RC2:

error NU1603: Microsoft.VisualStudio.Web.CodeGeneration.Templating 5.0.0-rc.2.20473.1 depends on Microsoft.AspNetCore.Razor.Language (>= 5.0.0-rc.2.20466.1) but Microsoft.AspNetCore.Razor.Language 5.0.0-rc.2.20466.1 was not found. An approximate best match of Microsoft.AspNetCore.Razor.Language 5.0.0-rc.2.20475.17 was resolved.

error NU1603: Microsoft.VisualStudio.Web.CodeGeneration.Templating 5.0.0-rc.2.20473.1 depends on Microsoft.CodeAnalysis.Razor (>= 5.0.0-rc.2.20466.1) but Microsoft.CodeAnalysis.Razor 5.0.0-rc.2.20466.1 was not found. An approximate best match of Microsoft.CodeAnalysis.Razor 5.0.0-rc.2.20475.17 was resolved.

error NU1603: DevBetterWeb.Web depends on Microsoft.EntityFrameworkCore.Sqlite (>= 5.0.0-rc.2.20451.13) but Microsoft.EntityFrameworkCore.Sqlite 5.0.0-rc.2.20451.13 was not found. An approximate best match of Microsoft.EntityFrameworkCore.Sqlite 5.0.0-rc.2.20475.6 was resolved.

[anangaur]

/cc: @JonDouglas

[MarkKharitonov]

@aolszowka - this is precisely our problem. Microsoft.ReportingServices.ReportViewerControl.WebForms depends on Microsoft.SqlServer.Types like this:

    <dependencies>
      <dependency id="Microsoft.SqlServer.Types" version="14.0.0" />
    </dependencies>

The closest version of Microsoft.SqlServer.Types on Nuget is 14.0.314.76. Trying to install results in:

NU1603: Microsoft.ReportingServices.ReportViewerControl.WebForms 150.1404.0 depends on Microsoft.SqlServer.Types (>= 14.0.0) but Microsoft.SqlServer.Types 14.0.0 was not found. An approximate best match of Microsoft.SqlServer.Types 14.0.314.76 was resolved.
Package restore failed.

So, for some reason this warning seems to actually fail the install.
@davidfowl - please advise.

[MarkKharitonov]

https://stackoverflow.com/questions/64731043/how-to-install-microsoft-reportingservices-reportviewercontrol-webforms-nuget-pa

[dominikjeske]

Any ideas why this error is displayed only on one machine but on others there is no message at all?

warning NU1603: CoreWCF.Primitives 1.5.1 depends on Microsoft.Extensions.ObjectPool (>= 2.1.6) but Microsoft.Extensions.ObjectPool 2.1.6 was not f ound. An approximate best match of Microsoft.Extensions.ObjectPool 8.0.2 was resolved

All machines have SDK 8.0.200 - is there any global switch, environment variable or something to control this behavior?

[zivkan]

The two machines are probably using different package sources.

We highly recommend that all repos/solutions have a nuget.config file set up to make the package sources deterministic (have a nuget.config file where the first element under <packageSources> is <clear/>).

This way your solution is not subject to different user configurations on different machines.

[dominikjeske]

I have nuget.config but I have some trash in user configuration - I never touch this files but clear them was solution for me. Thanks.