Visual studio conflicts between Reference and Platform

Question

Since I upgraded my target framework to 4.6.1 for a C# ASP.Net project I get a lot of conflict warnings during build. 50+ Messages like:

Consider app.config remapping of assembly "System.Runtime.InteropServices.RuntimeInformation, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "0.0.0.0" [] to Version "4.0.2.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Runtime.InteropServices.RuntimeInformation.dll] to solve conflict and get rid of warning.

They are all related to .NET System library. I could of course remap all references but somehow I think that is not the proper solution. If I rebuild with output 'detailed', I get more information:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.ConflictResolution.targets(33,5): message NETSDK1041: Encountered conflict between 'Reference:System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Reference:System.Runtime.InteropServices.RuntimeInformation'. NETSDK1033: Choosing 'Reference:System.Runtime.InteropServices.RuntimeInformation' because AssemblyVersion '4.0.2.0' is greater than '4.0.1.0'.

Somehow there seems to be a version conflict between a .NET framework in the folder C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.1 and C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib.

I don't know how to make sure it uses references from the same place. Can anyone help?

Answer 1

Visual studio conflicts between Reference and Platform

It seems because that:

This is due to the injected support for NETStandard 2.0. We inject new assemblies into NET 4.6.1 and later desktop projects in order to add support for netstandard2.0. We do this in targets now instead of packages because its no longer a requirement to reference a package to build a netstandard library. This injection happens whenever we see a netstandard1.5 or greater library referenced (see dotnet/sdk#1386).

To resolve this issue, you could add binding redirect to those reference.

Check System.Net.Http v4.2.0.0 being copied/loaded from MSBuild tooling for some more details.

Hope this helps.