Bug:Build failure due to namespace changes in XamlTypeInfo after C++/WinRT update

[takatsuka2022]

Describe the bug

In cppwinrt version 2.0.240111.5

I'm experiencing a build failure when referencing a WinUI 3 runtime component (root namespace: Control1) in a WinUI 3 project (root namespace: App1). The namespaces registered in App1's XamlTypeInfo are different before and after updating C++/WinRT.

Before the update, the entry in XamlTypeInfo looks like this:

L"Control1.UserControl1", L"",
&ActivateType<::winrt::Control1::UserControl1>, nullptr, nullptr, nullptr,
121, // Microsoft.UI.Xaml.Controls.UserControl
85, 0, -1, TypeKind::Metadata,
TypeInfo_Flags_None,
-1,

After the update, it changes to:

L"Control1.UserControl1", L"",
&ActivateLocalType<::winrt::Control1::implementation::UserControl1>, nullptr, nullptr, nullptr,
121, // Microsoft.UI.Xaml.Controls.UserControl
85, 0, -1, TypeKind::Custom,
TypeInfo_Flags_IsLocalType | TypeInfo_Flags_None,
-1,

Steps to reproduce the bug

I'm experiencing a build failure when referencing a WinUI 3 runtime component (root namespace: Control1) in a WinUI 3 project (root namespace: App1).

Expected behavior

No response

Screenshots

No response

NuGet package version

None

Windows version

No response

Additional context

No response

[DarranRowe]

Was it just C++/WinRT that changed?
I ask this because C++/WinRT isn't responsible for the generation of any of the files involved in XamlTypeInfo. The way the build process works is:

1. Midl compiles the .idl files into the individual .winmd files. You can find these in $(IntDir)\Unmerged.

2. Mdmerge merges these individual .winmd files into the application combined .winmd file. So it reads the files from $(IntDir)\Unmerged and writes to $(IntDir)\Merged\$(RootNamespace).winmd.

3. It copies this merged .winmd file to $(OutDir).

4. Cppwinrt runs for the first time. This run generates the basic platform headers. These are stored in $(ProjectDir)\Generated Files\winrt.

5. Cppwinrt runs for the second time. This run generates additional platform headers, this would include SDK references. These are stored in the same place.

6. Cppwinrt runs for the third time. This run reads the application .winmd files and produces the component headers and implementation source. These are stored in the same place. This means that C++/WinRT is responsible for reading the .winmd file and generating .h files under $(ProjectDir)\Generated Files\winrt.

7. The first Xaml Compiler pass runs. This reads the various .winmd files and produces some header and source files under $(ProjectDir)\Generated Files.

8. The second Xaml Compiler pass runs. This reads the various .winmd files and the state from the first pass and produces the remaining source files, this is when XamlTypeInfo.cpp should be generated.

So I could understand an update to the Windows App SDK package causing this, since that is what contains the Xaml Compiler. But an update to C++/WinRT shouldn't cause this.

[kennykerr]

Possibly related: microsoft/cppwinrt#1397

[Scottj1s]

@takatsuka2022 Can you share a repro project?

[takatsuka2022]

We have created a test pro. We have also confirmed that the solution builds successfully and is executable by reverting the CppWinRT version back to 2.0.230706.1.
ControlLib 2.zip

[Scottj1s]

@takatsuka2022 thank you for the repro. A fix has been made to CppWinRT: microsoft/cppwinrt#1404

[Scottj1s]

Fix has been published: https://www.nuget.org/packages/Microsoft.Windows.CppWinRT/2.0.240405.15