C++/WinRT can only consume 1 authored component nupkg

[j0shuams]

Describe the bug
Only one authored component gets used properly by a C++/WinRT app referencing two authored components.

To Reproduce

1. Make two separate C#/WinRT components
2. Have both generate nupkgs
3. add those nupkgs as references to a C++/WinRT app

Expected behavior
C++ projection gets made for both component winmds.

[raffaeler]

For your info, in my scenario I can't obtain any valuable information when adding <CppWinRTVerbosity>high</CppWinRTVerbosity> to the .vcxproj file.
I am not sure other verbosity/logging setting exists

[j0shuams]

Thanks, I believe this is an issue with Nuget resolving assets/running the targets we ship with your component.
This target should be running for both components and adding both WinMDs to the C++/WinRT project. My starting theory is only one .targets is running.

[raffaeler]

I see, this may happen because the targets file specifies Implementation="WinRT.Host.dll" and, since the file already exists, the second component getting installed is skipped.
Interesting and convincing theory

[asklar]

@jonthysell does this sound related to the nuget issues you were seeing with consuming from cppwinrt?

[j0shuams]

@raffaeler I appreciate your patience with this issue. I have root caused this to how we distribute build targets for winrt components. If you have two authored components Alpha and Beta, each with a nupkg, then they have Alpha.targets and Beta.targets. These targets files are the same because they are a template we provide in cswinrt.

The issue you have found is that the targets that need to run for Beta have the same name as the ones for Alpha. So Alpha is built, a projection gets made, everything goes well; then Beta tries to build and MSBuild skips its targets because it thinks they are the same as Alpha's and thus have already been executed.

Working on a solution, but thought it was an interesting turn of event to share.

[andrewleader]

@manodasanW FYI, 1.3.3 was already released and the pull request hasn't been merged, I don't think this made it into 1.3.3 😊 Looking forward to the fix though, I noticed this problem too when playing around with WinUI 3 C++ app and couldn't get using two C# NuGet packages to work, only using one at a time worked!

[andrewleader]

Oh nevermind... you do have it set to 1.3.4... GitHub simply doesn't update the milestone name when it says "manodasanW added this to the Release 1.3.3 milestone 2 days ago"... but after scrolling up (and also clicking on the link), I see that that milestone is now labeled 1.3.4. All good 😊