How to ignore NuGet NU1605?

Question

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:

• A Roslyn-based source code converter
• A bridge that implements the Unity 5 interface but in reality maps calls transparently to a wrapped Unity 4 container interface

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?

Phalanstery

Are the names of the assemblies that you will reference from those two packages the same? The file names I mean. It is very typical of nuget packages to contain assemblies that do not contain the version number, which means that your compiled output folder cannot contain two distinct versions of the files as they will have the same file name. If we ignore the nuget warning altogether, are you sure what you're asking for is even possible, at all? – Pretrice

I haven't checked the actual Unity DLL file names, however, I have a setup with unit tests that reference Unity 4.0.1, with the main project referencing Unity 5.11.1 as NuGet packages. All tests are passing, though the compilation does emit NU1605 as a warning, o I suspect the Assembly Identities are different which enables the CLR to load each version individually. – Phalanstery

Answer 1

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.

Dysgenic

Here's a sample of how nuget restore REDACTED.All.sln outputs NU1605 as an error, not a warning: Errors in C:\REDACTED\Services\Application\REDACTED.NativeAPI\REDACTED.NativeAPI.csproj NU1605: Detected package downgrade: Unity from 5.1.1 to 4.0.1. Reference the package directly from the project to select a different version. REDACTED.NativeAPI -> REDACTED.LegacyPlatform.Common 1.0.189-unity5 -> Unity (>= 5.1.1) REDACTED.NativeAPI -> Unity (>= 4.0.1) – Phalanstery

I've referenced the package as follows: <PackageReference Include="REDACTED.LegacyPlatform.Common" NoWarn="1605" PrivateAssets="all"> <Version>1.0.189-unity5</Version> </PackageReference> – Phalanstery

If you run msbuild /pp:pp.txt on REDACTED.NativeAPI.csproj, then search it for NU1605, I'm confident that you'll find something, probably the .NET SDK, elevates it to a warning using WarningAsErrors. NuGet raises it as a warning – Dysgenic

I ended up sidestepping the problem entirely by re-packaging Unity 5.11.1 as Unity5 5.11.1 on a private NuGet repo as a temporary measure to ease the migration process. Thank you for your help @Dysgenic – Phalanstery