crossgen2 fails when a Managed C++ dll is passed as a reference assembly

[AArnott]

Description

When trying to crossgen2 a C# assembly that was originally compiled with a reference to a Managed C++ dll, crossgen2 fails

This is not asking for support to crossgen a managed C++ dll. But given crossgen2 produces the best native code when the transitive closure of assemblies referenced by a C# assembly are provided, my build script passes in all the reference (or copy local runtime) assemblies. Filtering out the Managed C++ assembly is infeasible because my build script has no insight into the content of the ref assemblies to ascertain which are managed C++. If crossgen2 cannot process these, it should skip them (possibly emitting a warning) instead of emitting an error and bailing out.

Reproduction Steps

crossgen2 somecsharp.dll -r somemanagedcpp.dll

Expected behavior

A successful crossgen run. Ideally with fully compiled native code even in methods that reference APIs from the managed C++ assembly.

Actual behavior

The assembly cannot be crossgen'd at all.

Internal.CommandLine.CommandLineException : error : managed C++ is not supported: (managed c++ dll path)

Regression?

No response

Known Workarounds

I manually drop the reference to the Managed C++ assembly from the CLI and it starts working.
Note this works even while the c# assembly retains the reference to the managed C++ assembly itself.

Configuration

No response

Other information

No response

[AArnott]

#38096 might be related.

[MichalStrehovsky]

This might be as easy as deleting the current detection and enabling the check that NativeAOT compiler uses: dotnet/runtimelab#1046 (remove ifdef)

Might want to change the exception to be a TypeSystem one so that it doesn't crash the compiler and instead takes the codepaths that we e.g. have for unresolvable references.

[trylek]

I agree that non-destructive behavior is probably more appropriate, in contrast to NativeAOT we just need to make sure that a bug doesn't end up incorrectly marking all assemblies as Managed C++ as that's a "non-destructive" bug in Crossgen2 but still one we don't want to tolerate as it would cancel all R2R perf wins; so we should probably either add a command-line option to suppress the failure or just make it a failure for the "main" input files but not for the "reference" files.