XamlTypeInfo.g.cpp adds providers for project references, but doesn't #include needed headers

[DefaultRyan]

(See discussion started here: microsoft/WindowsAppSDK#763)

• Create a blank WinUI app (App1)
• Add a WinUI Runtime Component (Controls1)
• Using the template, add a UserControl to the Runtime Component (Controls1)
• Add a project reference in the app to the component (App1 references Controls1).

Building the project after this results in a build error in XamlTypeInfo.g.cpp:

std::vector<::winrt::Microsoft::UI::Xaml::Markup::IXamlMetadataProvider> const& XamlTypeInfoProvider::OtherProviders()
{
    if (_otherProviders.empty())
    {
        _otherProviders.push_back(::winrt::Controls1::XamlMetaDataProvider()); // <-- ERROR
        _otherProviders.push_back(::winrt::Microsoft::UI::Xaml::XamlTypeInfo::XamlControlsXamlMetaDataProvider());
    }
    return _otherProviders;
}

This breaks because the header for Controls1 wasn't included. XamlTypeInfo.g.cpp should have this added:

#include <winrt/Controls1.h>

It's possible to work around this by adding the missing #include to the precompiled header (pch.h), but XamlTypeInfo.g.cpp really should be self-sufficient.

[StephenLPeters]

@evelynwu-msft FYI

[evelynwu-msft]

@RealTommyKlein I remember this coming up before around the Preview 1 timeframe, but I don't recall why we left it the way it was.

[RealTommyKlein]

@evelynwu-msft - IIRC that was a slightly different self-sufficiency issue that we fixed (some of the compiler's generated code relied on the default pch.h - if the default #includes were removed, we'd get errors similar to this bug). For this issue in particular, the compiler needs to dynamically determine which headers it needs to include.

I don't think that would be too difficult for XamlTypeInfo.g.cpp since we know all the types we're generating for, and can determine the header name to include by the types' namespace (e.g. if we're generating type info a Controls1.UserControl, we need to include the <winrt/Controls1.h> header). We should also do the same thing for our generated per-page files like MainPage.xaml.g.hpp that gets generated for a MainPage.xaml. For them, we'd need to associate which pages use which types so we know which headers to include for each page, which would also lay the foundation for future incremental build improvements by only reparsing .xaml files which we know contain changed types.

[duncanmacmichael]

Fixed in 1.4.0. @bpulliam please close this issue as I cannot. :)