CODEWITHSUNDEEP
c#nugetunity-container
Machinarius
Machinarius

Reputation: 3731

How to ignore NuGet NU1605?

I have a huge solution with many projects and in-house NuGet packages that has a pervasive dependency on Unity 4.0.1. We are evaluating migrating this solution to Unity 5.11.1 to improve performance and solve random DI-related crashes stemming from code that the Unity project outright deleted on the 5.0.0 release.

In searching for a way to ease the migration from the outside-in two tools have been developed:

Both tools pass their unit tests just fine and the converter managed to convert one key "leaf" project, however, we've hit a roadblock when trying to reference migrated leaf project from one inner project: The infamous NU1605.

I absolutely can see how the NU106 error is warranted, as the inner project still references Unity 4.0.1 and the leaf project references Unity 5.11.1. however, this is one case of the tools getting in our way: I require both versions to "co-exist", as I am manually bridging their inconsistencies.

On paper, this should be plenty viable as the DLLs have different versions and even namespaces are different.

Is there any way to "force" nuget into accepting this weird setup?

Upvotes: 9

Views: 7154

Answers (1)

zivkan
zivkan

Reputation: 14981

You have two options to suppress that code. One is to use the <NoWarn>NU1605</NoWarn> msbuild property (must be defined inside a PropertyGroup). Visual Studio's project properties probably has a way to edit it in the UI.

The other option is to add the NoWarn="NU1605" metadata to your PackageReference item:

<PackageReference Include="package id" Version="1.2.3" NoWarn="NU1605" />

Finally, NuGet actually reports NU1605 as a warning, which you might notice if you read the docs page title carefully. The .NET Core SDK elevates it to an error using the WarningsAsErrors property. So, if you're sufficiently proficient with MSBuild, you could either remove it after they add it, or check how to prevent it from being added to the list. My guess as to the motivation is because the BCL is being distributed as packages for .NET Core 1.x and 2.x (it won't for 3.x) and when there's a security update, you don't want NuGet's nearest-wins rule causing a package with a known vulnerability to be accidentally used.

Upvotes: 16

Related Questions