Warning C4691 when building a C++/CLI executable: ignore or repair?

Question

When using assemblies from NuGet, I am virtually guaranteed to encounter this warning.

Our code base is mission critical. Are these warnings going to pose a threat to our code stability and performance? If so, how do I repair the warning condition so that instability is not an issue?

Warnings appear as follows:

>c:\projects\ucpro\application\ucpront\logging.h(33): warning C4691: 'System::Exception': type referenced was expected in unreferenced assembly 'System.Runtime', type defined in current translation unit used instead
>c:\projects\ucpro\application\ucpront\logging.h(33): note: This diagnostic occurred while importing type 'Microsoft::Extensions::Logging::ILogger ' from assembly 'Microsoft.Extensions.Logging.Abstractions, Version=1.1.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
>c:\projects\ucpro\application\ucpront\logging.h(33): warning C4691: 'System::Func': type referenced was expected in unreferenced assembly 'System.Runtime', type defined in current translation unit used instead
>c:\projects\ucpro\application\ucpront\logging.h(33): note: This diagnostic occurred while importing type 'Microsoft::Extensions::Logging::ILogger ' from assembly 'Microsoft.Extensions.Logging.Abstractions, Version=1.1.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

An easy example is when trying to use Microsoft.Extensions.Logger. One can easily reproduce the issue with this project

As seems to be a necessity, I am pulling the NuGet via a shim library which itself targets .NET 4.6 also, then directly pointing at the net46 folder to pull in the Microsoft.Extensions.*.dll 's.

The warnings seem like artifacts of assembly redirection from netstandard to .NET Framework

Answer 1

After opening an incident with Microsoft, here is the semi-canonical answer. Semi-canonical because

• This is paraphrasing a long conversation and
• My notes are not here, so I can't double check every detail.

Answer: Under the conditions where the project's referenced assembly is mscorlib but in fact the referencing class is looking for the referenced class in assembly System.Runtime, these warnings may be safely ignored as System.Runtime is (largely) to netstandard as mscorlib is to .NET Framework.

My own observations - not specifically coming from my incident gleanings: Under more normal (non C++/CLI) conditions, the compiler may use shim libraries to quell this error and apparently do a minor amount of adapter-pattern stuff as well