CsWinRT icon indicating copy to clipboard operation
CsWinRT copied to clipboard

Modify interop project to prevent winmd leaking from component project

Open angelazhangmsft opened this issue 3 years ago • 6 comments

Describe the bug

Referencing a C#/WinRT interop project from a .NET 5 app raises a NETSDK1130 error. This is because the component winmd flows through from the C++/WinRT component project. The project referencing structure is .NET 5 app -> .NET 5 library interop project -> C++/WinRT component.

Look into whether C#/WinRT can fix this either by:

  1. Setting the implementation dll as an output in addition to the projection dll for the interop project. Then in the interop project, authors would set <PrivateAssets>all</PrivateAssets> on the project reference to the C++/WinRT component. Caveat is the component might have multiple binaries
  2. Modifying cswinrt NuGet targets. Cswinrt needs to influence reference resolution before project references kick in - binlog would show cross-reference target evaluation and the hook for that change. Referring to the CsWinRTRemoveWinMDReferences target here: https://github.com/microsoft/CsWinRT/blob/d361800d2cf6a46d2c7d276126a09bab1d8bc1c4/nuget/Microsoft.Windows.CsWinRT.targets#L47

To Reproduce

  1. Build the Net5ProjectionSample without generating a NuGet package
  2. Add ConsoleAppSample to the sample solution and add a project reference to the interop project, SimpleMathProjection

Here's an example - https://github.com/angelazhangmsft/ProjectionProject

Expected behavior

WinMD doesn't flow through but implementation dll does.

Additional context Current workaround for consuming interop project by project reference is to add cswinrt NuGet reference in app

angelazhangmsft avatar Mar 03 '21 19:03 angelazhangmsft

May be fixed if NETSDK1130 is resolved

angelazhangmsft avatar Mar 11 '21 19:03 angelazhangmsft

Possible way to fix this is to have the interop project add metadata to the TargetPath item it returns with the name of the WinMD that the interop project is wrapping. Then we could add logic so that the consuming project could filter out the transitive WinMD reference that it gets, similar to how we are removing WinMD references with WinRT.Host.dll as the implementation

angelazhangmsft avatar Apr 26 '21 21:04 angelazhangmsft

Just ran into this. It's my first time using CsWinRT and it's the second 6+ month old bug I've run into.

Corillian avatar Jan 05 '22 04:01 Corillian

@Corillian - unfortunately we haven't been able to investigate this further yet. As a workaround, you can add a package reference to Microsoft.Windows.CsWinRT in your app to avoid the NETSDK1130 error.

Depending on your scenario, you might also want to take a look at the recent embedded support which allows you to compile projection/runtime sources into your app or library for self-contained usage of WinRT types.

angelazhangmsft avatar Jan 05 '22 18:01 angelazhangmsft

I saw that in the earlier discussion, it worked, thanks for following up! While the future of WinUI3 sounds promising, lots of great things on the roadmap, it looks like it was released 6-12 months prematurely. Typically, the thing you guys (Microsoft) do best is toolchain support, but everything around WinUI3, including WinUI3 itself, seems to be pretty rough at the moment. Working with it is a bit frustrating.

Corillian avatar Jan 05 '22 19:01 Corillian

@ocalvo has demonstrated that this works: <PrivateAssets>build</PrivateAssets>

Scottj1s avatar Apr 12 '22 21:04 Scottj1s