Reference assemblies for C++/CLI assemblies cannot be used in WPF projects

[Stefan137]

I'm using Refasmer to generate reference assemblies for mixed assemblies (C++/CLI, .NET Framework 4.8) using the --public option. Building C# projects against these reference assemblies works great in general but fails when the C# project uses WPF. The build error typically reads as follows:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9): error MC1000: Unknown build error, 'Could not load file or assembly 'MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Signature missing argument. (Exception from HRESULT: 0x801312E3)'

The error appears even for extremely simple mixed assemblies - e.g., assemblies containing just a single public type with no members. Apparently, mixed assemblies always contain an internal <Module> type in the global namespace. I've not yet seen the <Module> type in managed-only assemblies.

There is special handling for <Module> in the code. I've removed it for testing purposes so that <Module> is no longer included in the reference assemblies. These reference assemblies can then successfully be consumed in C# WPF projects. However, I do not yet know the meaning of the <Module> type, the impact of ignoring it, and why the special handling has been added.

[Stefan137]

Unfortunately, my proposed fix did not work under all circumstances - afterwards, some of my productive reference assemblies caused the following error in a C# WPF project:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9): error MC1000: Unknown build error, 'Could not load type 'System.Runtime.CompilerServices.ReferenceAssemblyAttribute' from assembly 'MyAssembly, Version=10.0.0.0, Culture=neutral, PublicKeyToken=null'.'

I've not yet understood why the type isn't searched in mscorlib.dll. However, this error dissapears when I use the --internals option instead of --public. In fact, reference assemblies generated by Visual Studio for C# projects contain internals as well, so this choice seems reasonable to me.

Therefore I've added special special handling for the type again, now always enforcing that is ignored. After this modification, my C# WPF projects are building successfully so far.

[Stefan137]

Note: It seems that <Module> is an artificial .NET class where global functions and variables end up¹. As they are not intended to be used by dependent assemblies, I guess it wouldn't hurt if <Module> didn't show up in reference assemblies generated by Refasmer.

Footnotes

1. https://stackoverflow.com/a/42884913/3445735 ↩

[ForNeVeR]

C++/CLI assemblies may easily depend on the global symbols from each other (or at least I think so), so I don't think that we should just cut it out.

Could you please give some more details about your case? An MCVE would be great, but some more details is also good.

What exactly throws the error? What kind of project is it (new SDK / old SDK), and what's the target framework?

Perhaps also attach a msbuild binlog (collected by dotnet build /bl) for further investigation.

I would theorize that XAML compiler tries to load some assemblies and fails if they are refasmed, but that's a long shot.

[Stefan137]

We have a solution A which contains some C++/CLI and C# library projects. And we have a solution B containing C# projects only, some of which are WPF projects depending on projects from A. All these projects are currently targeted against .NET Framework 4.8. The projects in B have not yet been updated to SDK style, so they use the old style.

Assemblies from A are also used in other solutions, and we want them to be able to build AnyCPU assemblies only. Of course, we take care in the deployment step that x86 and x64 versions of the C++/CLI assemblies are available as needed at runtime. During build time, AnyCPU reference assemblies of A are used. We are using Refasmer to produce the reference assemblies of the C++/CLI projects in A since it is the only tool we know of for doing so.

I have created an MCVE. How should I best provide it to you?

The MCVE contains a WPF old-style project and a WPF SDK-style project for comparison reasons. For simplicity, the C# projects in the MCVE are built for the x86 or x64 platform, not for AnyCPU. They still use a Refasmer-generated reference assembly of a C++/CLI project at build time. Interestingly, I obtain the following error (also mentioned in my initial comment) only when building the WPF old-style project, and only in the "Debug x64" configuration:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9): error MC1000: Unknown build error, 'Could not load file or assembly 'Mixed, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Signature specified is zero-sized. (Exception from HRESULT: 0x80131237)'

In all other cases, the WPF project apparently builds and runs just fine.

As far as I understand, it is only the .NET API that matters in reference assemblies, not the implementation. As we are not explicitly calling anything from <Module>, I guess we would not need it in a reference assembly - but I might be wrong.

It seens interesting to me that the presence and contents of <Module> in the reference assembly within the MCVE seems to depend on the configuration and platform:

• for Release x64:
  
• for Debug x64 <Module> is empty:
  
• for Release x86 <Module> is missing:
  
• for Debug x86:
  

Please let me know if any further information would be helpful.

[ForNeVeR]

I have created an MCVE. How should I best provide it to you?

Could you just drop a .zip archive here on GitHub? It handles small file uploads nicely (for me at least).

I'd also ask in advance for permission to use the uploaded data under the terms of Apache2 license (same as Refasmer uses), to probably push it into the repo for test purposes. If you don't allow it, that's also okay, but I'll have to reconstruct a similar example myself to use in tests.

As far as I understand, it is only the .NET API that matters in reference assemblies, not the implementation. As we are not explicitly calling anything from , I guess we would not need it in a reference assembly - but I might be wrong.

I still disagree with this statement: C++/CLI assemblies may depend on managed API of each other published as part of <Module>. <Module> is a valid way to publish managed API, even if it's hard to use from C#.

Refasmer is a tool for general purposes, and shouldn't silently discard these things.

Though I think it's okay to add an option if we've no other workaround.

From the error message, I still think we'll be able to fix it properly. It looks like Refasmer damages the native code section of a C++/CLI assembly, or something like that. It may be a bug in Cecil, but more likely a fault of our own code, and we'd need to experiment a bit to preserve the necessary semantic of <Module>.

[Stefan137]

Here you are: MCVE.zip

I hereby grant you the permission to use the content of the ZIP file under the terms of Apache License 2.0.

A few hints:

• If you don't have Refasmer on your path, you can install it as a local tool in the solution with dotnet tool restore.
• I've made the necessary adjustments to the C++/CLI project (called "Mixed") in PropertySheet.props where possible to make my adjustments more recognizable.
• A post-build step moves Mixed.dll into a subdirectory and executes Refasmer to produce the reference assembly in the place where Mixed.dll was before.
• The content of the C# projects mostly stems from the WPF project templates. I've added a project reference to Mixed.vcxproj and a <Content> tag which copies the implementation DLL.

[Stefan137]

I agree, a more thorough solution than just ignoring <Module is desirable.

By the way, looking into the Debug x64 DLL that served as an input for Refasmer, I can see that <Module> has some public members that appeared, for example, in the Release x64 reference assembly, but not in the Debug x64 reference assembly where <Module> was empty:

[zabbius]

Just in case, Refasmer does not use Cecil. Only Microsoft.CodeAnalysis.Common and System.Reflection.Metadata

[ForNeVeR]

Yep, that's my bad. Dunno why I inserted a Cecil mention there.