MDM2009 duplicate type error when using a grandchild reference

[RealTommyKlein]

Scenario: creating a CppWinRT app "App" with two WinRT components "B" and "C" with the following dependencies/references:

• App references B and C
• B references C

B will copy C.winmd to its output directory since it's a dependency. App will pass B and C's output directories as metadata directories to mdmerge since they are dependencies. However, because C.winmd is present in both B and C's output directories, App's mdmerge will fail because it detects duplicate types in the two C.winmds it evaluates.

[mediabuff]

Any fix in sight ? A show stopper for real world cppwinrt apps. This important issue was raised 6 months back (#318, #454), . MS folks closed it without any reason. Is MS (all related teams in MS) serious about supporting c++ and xaml ?

[kennykerr]

The msbuild support is a volunteer effort at this stage. @jlaanstra is doing most of that volunteering and hopefully he can get to this one at some point. As a workaround, you can always call midlrt, mdmerge, and cppwinrt from pre and post build steps. That's what I typically do and it works reliably. It's harder to set up, but more complex C++/WinRT projects tend to do just that. You can also restructure your project to avoid the dependency graph issues above. As for C++ and Xaml, I don't think that's going to be practical until C++ supports reflection and can produce the metadata that the Xaml toolchain requires. Again, it can be done manually but it is hard. The Xaml framework itself is built that way. https://github.com/Microsoft/microsoft-ui-xaml

[mediabuff]

Kenny, thanks for your response. I am not convinced by your arguments. One app referencing a DLL and that in turn referencing another DLL ? Complicated ? We have total broken tool chain even for the simplest of the use cases. MS teams don't seem to get their collective act together. This doesn't require 'reflection' etc. I don't think any body in MS is seriously using cppwinrt the inbox/publicly available toolset. This is in sane - after how many years of winrt/UWP/Xaml - we can't seem to develop simple apps in c++.

can also restructure your project to avoid the dependency graph

I am not sure the issue is being genuinely understood. Your suggestion is not possible. This is the same guidance I got one year back. One app and one control library reference standard Win2D package ? how will you break transitiveness ?

[kennykerr]

You're preaching to the choir. I realize the we have problems (darkness, xaml) and I continue to champion those within Microsoft, but there's only so much I can do.

I don't think any body in MS is seriously using cppwinrt the inbox/publicly available toolset.

That's not entirely true. There are a few heavily used MS apps that use both C++/WinRT and its build support. There are also many many top apps for Windows that use C++/WinRT (with or without build support) including many Windows and Office apps, Adobe products, Spotify, and much more.

So yes, Visual Studio integration continues to be a sore point and developing "simple" apps with C++ may not be that practical but investing in large scale development with C++/WinRT has certainly been very successful for many professional developers.

[mediabuff]

Others may using this for non-Xaml work effectively or simpler single DLL situations like Microsoft.UI.Xaml. . For Xaml apps, we a long way to go. This particular issue is not build tool issue. I have tried various complicated Msbuild scriptis to intercept midlrt - but was fighting against a conceptual problem in mdmerge. There is a fundamental arch issue with midlrt/mdmerge. Can only be fixed by fixing midlrt/mdmerge. Would be glad to help - but these tools are not open source.

[kennykerr]

Yes, midlrt and mdmerge have many problems. I'm working very hard to make those tools unnecessary in the future, but that's another story. 😉

[jlaanstra]

This is something that needs to be addressed in mdmerge.exe which ships as part of the Windows SDK. As a workaround you can use:

<ItemDefinitionGroup>
    <Reference>
        <Private Condition="'$(ConfigurationType)' != 'Application'">false</Private>
    </Reference>
</ItemDefinitionGroup>

[mediabuff]

Thanks for a potential approach. I assume this goes in project B's project reference to C ? Let me try this. The challenge is Win2D is referenced by a nuget install via Win2D.uwp.targets. So there is no direct reference in project B.

[jlaanstra]

@mediabuff the above simply changes the default for all items in the Reference itemgroup, so as long as Win2D doesn't explicity set it to true (which it shouldn't), this should work correctly.