Describe the bug
We have a large (104 DLLs and 1 EXE referencing all the DLLs) UWP app that was ported from WPF into UWP. The app uses many custom Xaml controls and forms spread out in ~50 DLLs. In Release with NET Native enabled, the app launches quickly (~3 seconds). In Debug, however, the code execution goes from App.cs into autogenerated XamlTypeInfo.g.cs, there it goes into GetXamlType(string fullName) where it calls Provider.GetXamlTypeByName(Provider being ReflectionXamlMetadataProvider) and at this point it starts loading all 104 DLLs into the memory which takes ~17 seconds on a fairly powerful machine to complete (8-core i7, 32GB RAM, SSD). This makes the UWP app impossible to use in Debug on HoloLens where this method takes ~1 minute to complete, because HoloLens determines that the app is not responding and shuts it down before we get to execute any code.

Steps to reproduce the bug
I guess you need many DLLs that contain a lot of XAML. Unfortunately, I can't share our code base. Then I think the behavior might be related to the following App.xaml.cs we are using:
sealed partial class App : MobileApplication, IServiceProvider

<mvvm:MobileApplication
…

Basically, we've derived our own App class in order to have our own bootstrap and IoC container. The call into GetXamlTypeByName tries to look for MobileApplication class.

Expected behavior
The call into GetXamlTypeByName should not load all our DLLs into the memory which takes too long and I assume it also uses a lot of reflection. We didn't have this issue before updating to 1809 where all the UWP projects started referencing Microsoft.UI.Xaml.Markup by default.

Screenshots

Version Info
Windows 10 1903, UWP app has Min/Target versions set to 1809.

NuGet package version:
Microsoft.NETCore.UniversalWindowsPlatform 6.2.9

Additional context