Why distribute everything in a single NuGet package?

[mrlacey]

Following on from #593 (comment)

Why will the only way to get any part of Project Reunion be by installing the Project Reunion NuGet package?

I understand the technical implementations of how meta packages work but worry that it means people needing to know more than is necessary.

For example:
With WinUI3 only being available as part of Project Reunion we're already seeing people being confused and thinking they're one and the same.
Now, imagine in a few months time (hopefully) and someone wants to use MRTCore in a WPF app. They need to add the Project Reunion package.
Now it's necessary to explain that:

• MRTCore is part of Project Reunion.
• Project Reunion & WinUI3 are not the same
• the references to WinUI3 inside the WPF app (a different framework) can be safely ignored.

The could be avoided if a reference to the MRTCore package could be added directly.

I appreciate the value of having a single meta package to make installing everything possible when wanted but don't see why this is a reason to not allow installing individual packages if that's what a developer wants.

Related question: How will parts of Project Reunion that aren't libraries be distributed?

The "everything is in the NuGet package" message is diluted when there are things that aren't (and can't be) in a NuGet package.
At the moment this is only a VSIX containing the WinUI3 templates but with other tooling going to be added to Project Reunion this is expected to grow in number.

[andrewleader]

Thanks for posting this Matt.

Question for you (and anyone else): You said you don't see a reason to not allow installing individual packages, however, I'll reframe that question back to you: "What's the harm in having to install a single package that contains everything?"

You listed the potential confusion that you have to explain MRTCore is part of Project Reunion, however, at some point some sets of technology would have to be bundled together. For example, in the notifications space, there's push notifications and local notifications. What if you just want to use local notifications? You'd still probably have to install the "notifications" package, which also includes push. Similar for UI controls, what if you only want to use the ColorPicker? It's unlikely that would be distributed as a separate package, so you'd still have to explain that it's part of WinUI.

Is there another concern aside from the potential confusion of how products are bundled? I'm not saying that's an invalid concern, just trying to see if there's anything else - agreed this is a valid concern and we need to help developers understand how it all fits together (and having a temporary name like Project Reunion doesn't help).

[DrusTheAxe]

it's impossible to use WASDK DynDeps if a project refers to WinUI 2 for XAML islands, as WinUI 3 will conflict.

How are you using both? Are you using both dynamically?

[sylveon]

I do not want to be using WinUI 3 but the "single package" practice means that if I want to use WASDK DynDeps to dynamically use WinUI 2, I have to install the Nuget, which forcibly brings in WinUI 3, resulting in conflicts. I have not yet tried using DynDeps with WinUI 2 because of this limitation.

[DarranRowe]

@DrusTheAxe
I knew of the very annoying issue of if you add both WinUI 2 and 3's nuget packages to a project then two references to Microsoft.UI.Xaml causes major issues on the project side.
But there was another problem that I had completely forgotten about. If you bootstrap the Windows App SDK in a process and tried to activate any WinUI 2 runtime classes then it would always try to use the WinUI 3 activation factory. The worst part about this is that doing some tests on Windows 11 shows bootstrapping the Windows App SDK just blindly hijacks all WinUI activation attempts. So as an example, suppose you have code similar to the following:

add_winui_2_package_reference(8);

auto xmdp = winrt::Microsoft::UI::Xaml::XamlTypeInfo::XamlControlsXamlMetaDataProvider();

The first function does the heavy lifting of calling Windows 11's TryCreatePackageDependency/AddPackageDependency. This loads the WinUI 2's Microsoft.UI.Xaml.dll and activates it as expected. However, suppose you have something similar to the following:

add_winui_2_package_reference(8);
call_mddbootstrapinitialize_in_separate_dll();
auto xmdp = winrt::Microsoft::UI::Xaml::XamlTypeInfo::XamlControlsXamlMetaDataProvider();

This fails to activate because it loads the WinUI 3's Microsoft.UI.Xaml.Controls.dll. The Windows App SDK NuGet package is referenced in a separate DLL, so the main executable is seeing the WinUI 2 type information. After digging around a little, there seems to be a detour in RoGetActivationFactory and this is what chooses the WinUI 3 activation factory.

[DrusTheAxe]

I knew of the very annoying issue of if you add both WinUI 2 and 3's nuget packages to a project then two references to Microsoft.UI.Xaml causes major issues on the project side.

But there was another problem that I had completely forgotten about. If you bootstrap the Windows App SDK in a process and tried to activate any WinUI 2 runtime classes then it would always try to use the WinUI 3 activation factory.

Same difference. WinUI2 and WinUI3 have the same types and symbol names. If both WinUI2+WinUI3 are in the process' hunt sequence for WinRT activation then what Microsoft.UI.Xaml.Controls.Button resolves to depends on what's found first - and what's already been accessed, what tech is in play (ABI vs C++/WinRT, manifest-free vs SxS vs MSIX registration, ...).

TL;DR WinUI2 and WinUI3 can't cohabitate in the same process, and since WinUI3 is part of WinAppSDK mixing WinUI2 and WinAppSDK is generally a non-starter.¹

¹ It's possible in theory to use some not-WinUI3 parts of WinAppSDK with WinUI2 in some very complex ways scenarios e.g. don't load Microsoft.WindowsAppRuntime.dll. But that's very much off the beaten path and waving to advanced territory in the rear view mirror...

If this folks are interested in mixing WinUI2 and WinAppSDK please open a discussion thread or issue with details about your scenario.

[DarranRowe]

I did end up having some success with this.
As an example, here is a partial output log from Visual Studio:

'XITest.exe' (Win32): Loaded 'C:\Windows\System32\OneCoreCommonProxyStub.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\execmodelproxy.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.4_4000.1010.1349.0_x64__8wekyb3d8bbwe\Microsoft.WindowsAppRuntime.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\xmllite.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\rometadata.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\powrprof.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\powrprof.dll'. 
'XITest.exe' (Win32): Unloaded 'C:\Windows\System32\powrprof.dll'
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\umpdc.dll'. 
onecore\base\appmodel\runtime\src\lookup.cpp(218)\kernelbase.dll!00007FFC1538F535: (caller: 00007FFC153F075A) ReturnHr(1) tid(a3a4) 8007007A The data area passed to a system call is too small.
onecore\base\appmodel\runtime\src\lookup.cpp(218)\kernelbase.dll!00007FFC1538F535: (caller: 00007FFC153F075A) ReturnHr(2) tid(a3a4) 8007007A The data area passed to a system call is too small.
onecore\base\appmodel\runtime\src\lookup.cpp(218)\kernelbase.dll!00007FFC1538F535: (caller: 00007FFC153F075A) ReturnHr(3) tid(a3a4) 8007007A The data area passed to a system call is too small.
onecore\base\appmodel\runtime\src\lookup.cpp(218)\kernelbase.dll!00007FFC1538F535: (caller: 00007FFC153F075A) ReturnHr(4) tid(a3a4) 8007007A The data area passed to a system call is too small.
'XITest.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Microsoft.UI.Xaml.2.8_8.2310.30001.0_x64__8wekyb3d8bbwe\Microsoft.UI.Xaml.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\d2d1.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\Windows.UI.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\Windows.UI.Immersive.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\Windows.UI.Xaml.dll'. 
'XITest.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'. 

This was collected recently as the versions show, but I did keep investigating earlier in the year. I ended up stopping due to there being progress on WinUI 3's Xaml Islands, so I never got around to properly testing this. I was using a DLL to contain the Windows App SDK functionality, so it was a messy layout.

[andrewleader]

And for your related question -> A VSIX extension potentially isn't our long-term vision. We're still defining the long-term vision for tooling, but I think it's likely we want the experience to be as seamless as WPF... the templates and tooling are already there, part of the VS install. Open to any feedback there.

[mrlacey]

If all tooling comes with VS:

• Does that mean it would be released as part of the VS release cycles or the Project Reunion ones?
• If in VS, presumably it would be part of a workload. Will this be a new one, a replacement for UWP, or something else?
• What about any tooling that is part of Project Reunion but not restricted to WinUI3? If a WPF developer wants this will they have to install an entire workload just to get one tool?
• What does that mean for anyone not wanting to use VS?

[Scottj1s]

It may not address all the concerns expressed here, but I wanted to call out that the Windows App SDK 1.8 Experimental 2 has been refactored into a proper metapackage (the original Project Reunion top-level package was not a true metapackage but contained non-trivial build logic and assets), enabling standalone use of any subset of components.

https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/experimental-channel#nuget-metapackage

[DarranRowe]

This is great.

My only question is how in synch are the packages expected to be. As an example, suppose an update comes out that doesn't include updates in DWriteCore, is the DWriteCore metapackage expected to stay unchanged?

[Scottj1s]

Good question. We're rolling this out carefully. Initially, only proper subsetting will be supported, via strict versioning - i.e., the metapackage will reference components with "[this_version_only]". At some point, we'd like to enable version overrides of specific components, but that will entail greater testing overhead. And yes, if a component such as DWriteCore has not been updated between releases of Windows App SDK, we will not require it to churn - components will version independently of the Windows App SDK metapackage.