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

[msedi]

NuGet Product(s) Affected

dotnet.exe

Current Behavior

Coming from #5764 I'd like to bring this up again. We have recently introduced the intel.mkl nuget packages into our project and we are being flooded with NU1603 warnings.

The reason is that the package is dependend on other packages

    <dependencies>
      <dependency id="intelopenmp.redist.win" version="[2023.0.0, 2024.0.0)" />
      <dependency id="inteltbb.redist.win" version="[2021.0.0, 2022.0.0)" />
    </dependencies>

But intel made the dependency floating to the latest possible version inside the range. I think this is a valid point but from the discussion #5764 it seemed that the package distributor should enter only dedicated version. If this is the case, why does this possibility exist at all to allow a range of versions while the behavior (at least what was discussed from some people in #5764) should be only one dedicated version.

I think this behavior was intended by intel, but it is presented as a warning which is isn't. It is only an information.

Because it is intended by intel but obviously not as desired by nuget my effort would be now to explicitly exclude the warning NU1603 everywhere in our codebase for only this package.

I think I will have a hard time to convince intel to change it ;-)

Desired Behavior

Either disallow to set a range or allow to suppress the warning if the behavior is intended.

Additional Context

No response

[Nigusu-Allehu]

As you mentioned it, this is a duplicate of #5764
Thank you for bringing this to our attention!

Using a version range for dependencies, as Intel has done, provides flexibility and ensures that consumers of the package automatically get bug fixes and improvements without requiring the main package to be republished every time a dependency is updated. This approach can be particularly helpful in scenarios where frequent updates are expected. However, the downside, as you've experienced, is the potential for warnings like NU1603 when the exact lower boundary version isn't available.

As discussed in #5764, the ability to specify a version range is a feature of NuGet to offer flexibility. It's up to package authors to decide how to use it. The lowest version in the range is the version that will be used in the build. However, if it does not exist, instead of stopping the build and printing an error, a version range allows users to continue building with another version. This is the flexibility provided from the feature. However, we would also like our users to be informed that the version they specified does not exist anymore and the next available version in the range was used for the build. Please feel free https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution#lowest-applicable-version to learn more about how NuGet resolves versions.

I understand the wording in the warning message can be confusing.

If you're sure that the resolved versions of these dependencies are compatible and won't introduce issues, you can suppress the NU1603 warning for the intel.mkl package using the NoWarn property in your .csproj files.

[msedi]

@Nigusu-Allehu: Thanks for the comment. I also though about the NoWarn, but the problem is that I then turn it off for the whole assembly also affecting other libraries, where it still makes sense to get the warning.

It would be more helpful, if I could directly turn it off on the PackageReference itself, so that only this package is affected by the NoWarn.

[nkolev92]

@msedi Have you tried setting NoWarn on the package itself? It's possible for direct packages, but not for transitive packages. There's a related issue #5740. For now, for transitive packages your options are to promote the package to a direct reference and no warn there or to warn project wide.

Team Triage: The NU1603 are by design warning when the lowest version of a range does not exist. Packages are expected to be built against existing package versions and not theoretical ones.

[msedi]

@nkolev92: Thanks for the info I was not aware of this. The only problem might be that there is still #5740 open that might cause problems, because this is exactly what I currently see. It does not seem to be solved at the moment, right?