Sdk: Warning C4691 when building a C++/CLI executable

[malachib]

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

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

We also explored the issue on MSDN

Also this is a semi-cross-post from here but it seemed like the logging folks aren't the right ones to bug. I felt this is a better spot to ask because the C4691 warning appears to be referring to a netstandard assembly.

If a) I am posting in the right place and b) you would like me to break it down more/provide more detail please let me know

[livarcocc]

cc @Petermarcu do you know how to make this work? I haven't tried it.

[Petermarcu]

@terrajobst as FYI,

No, I haven't tried it either.

[livarcocc]

I don't believe this to be an SDK issue. I see in the feedback item you created by VS, it has been stated that this is not supported on the VS side. As such, I am going to close this issue.

[malachib]

I ended up opening an incident. I think one could make an argument that SDK is strongly involved, but it's a combination of C++/CLI, VS and .NET Framework+.NET Standard interactions. Specifically those shim libraries which map System.Runtime over mscorlib... reality seems to be though that C++/CLI demand is too low to really stir up concern. Dang!

[pongba]

@malachib I'm having exactly the same issue when trying to use Roslyn in C++/CLI. Interesting how low C++/CLI demand is, AFAIK it's the best bridging language between native and .net.

[adaviding]

I am having this issue. My C++/CLI project is pulling in a netstandard2.0 project (not via nuget). I am using VS 2017 and I have .net core sdk 2.2 (dotnet --version = 2.2.107). (I am guessing this has nothing to do with nuget.)

[malachib]

@pongba I agree
@adaviding probably is relatively unrelated to nuget, if it's the issue discussed here

Also, I don't think I can share that old incident link here. Support request #118010217393556.

But for the record, MS depressingly marked as "won't fix" with a "minimum" severity - though, many of those details appear to be lost due to a bug/archiving on their side.

To their credit, they dug through the issue in great depth. Here's a pertinent quote:

Hi Malachi,

These warnings can safely be ignored. These warnings are thrown as Microsoft.Extension.Logger and its related assemblies are derived from System.Runtime.

The compiler wants to find the System.Object and other System. defined in System.Runtime as the definition of System.Object looks like this: extends [System.Runtime]System.Object in Microsoft.Extension.Logger.

What is happening is that the compiler has already loaded mscorelib.dll and it finds all the references to System.Object and other System. in mscorelib.dll. This makes the compiler think that there are two reference to system.Object and other System classes. Thus throwing the warning.

But, when we look at the implementation of System.Runtime, we see that the classes defined in it actually extern forward to either mscorelib.dll or System.core. So basically all the system. are always loaded from mscorelib.dll.

So these particular warnings with System.Object and System. can be ignored to be safe. But keep in mind that this warning occurring for other classes custom defined may cause a failure at runtime.

[adaviding]

@malachib I wonder if this is fixed in .net core sdk 3.1.0 ... rumor is C++/CLI (mixed mode assemblies) might be supported on Windows now. (I wish I had more time to investigate the rumor further.)

https://stackoverflow.com/questions/39140014/c-cli-support-in-net-core
https://github.com/dotnet/coreclr/issues/18013