Projectreunion: WPF doesn't compile with ProjectReunion

[dotMorten]

Describe the bug
I was trying to use MRTCore that is in ProjectReunion with a WPF application. But merely referencing the package breaks the build.

Steps to reproduce the bug

1. Create a WPF .NET 5 project. csproj:
2. Add the Foundation Package.
3. Optionally add settings that matches what the WinUI templates uses. it target/min version, appmanifest, runtime-identifers etc (albeit it doesn't seem to make much of a difference). Here's my project:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows10.0.19041.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <UseWPF>true</UseWPF>
    <Platforms>x86;x64</Platforms>
    <RuntimeIdentifiers>win10-x86;win10-x64</RuntimeIdentifiers>
    <ApplicationManifest>app.manifest</ApplicationManifest>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.ProjectReunion.Foundation" Version="0.5.0-prerelease" />
  </ItemGroup>
</Project>

Or use this repro sample:
App35.zip

1. Compile
2. Observe the compilation error:
   > 1>C:\Users\mn.nuget\packages\microsoft.projectreunion.foundation\0.5.0-prerelease\build\Microsoft.ApplicationModel.Resources.PriGen.targets(833,5): error APPX1639: File 'C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP.props' not found. See http://go.microsoft.com/fwlink/?LinkID=798187 for more information.

If compiling from commandline instead of from within VS, the error is slightly different:

C:\Users\mn.nuget\packages\microsoft.projectreunion.foundation\0.5.0-prerelease\build\Microsoft.ApplicationModel.Resources.PriGen.targets(833,5): error MSB4062: The "Microsoft.Build.AppxPackage.GetSdkFileFullPath" task could not be loaded from the assembly C:\Program Files\dotnet\sdk\5.0.201\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.Build.AppxPackage.dll. Could not load file or assembly 'C:\Program Files\dotnet\sdk\5.0.201\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.Build.AppxPackage.dll'. The system cannot find the path specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\mn\source\repos\WpfApp5\WpfApp5\WpfApp5.csproj]

Expected behavior
Application builds.

Version Info
.NET: 5.0.201
VS: 16.9.1
NuGet package version: Microsoft.ProjectReunion.Foundation 0.5.0-prerelease

| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | |
| May 2020 Update (19041) | Yes |
| November 2019 Update (18363) | |
| May 2019 Update (18362) | |
| October 2018 Update (17763) | |

Additional context

[huichen123]

Microsoft.ProjectReunion.Foundation is not designed to be used standalone. It doesn't include the implementation. You should use Microsoft.ProjectReunion instead.

[riverar]

@huichen123 But that brings in WinUI right? WinUI is not compatible with WPF in this context. How does one use MRT without bringing in WinUI?

Snippet from roadmap:

[huichen123]

unfortunately there is no ala carte support at this moment. maybe remove WinUI from microsoft.projectreunion.nuspec in the nuget cache.

[dotMorten]

Exactly what @riverar said.

[huichen123]

you want to file a new issue to not include WinUI. For your compile issue, you can work around by adding this to your csproj. But it won't let you run.

~
Windows
10.0
~

[riverar]

Hm. @andrewleader @jonwis Is there any scheduled _a la carte_ work? I don't see any, which means we're going to miss 0.5 release right? (The README currently states Reunion bits are 100% additive (only add what you need, leave the rest of your app as-is) which is currently untrue.)

[andrewleader]

@riverar if by a la carte you mean only include the MRT components in your distribution and not the WinUI components, that's not a supported scenario. Everything in Reunion is included in one framework package and distributed together as one. Since it's installed as a framework package, that means all apps share the same framework package, so even if you only want to use MRT or notifications, "having to" include WinUI and other components isn't a significant burden (doesn't add to your app's install size, etc).

The only time it's a burden is on download sizes if you choose to carry the Reunion packages within your own download (which you'd do if you need to support offline installs). But that impact is only at download-time and doesn't impact the installed size of your app.

The 100% additive statement applies to being able to use a single feature, like push notifications, without having to rewrite your entire app (which yes, in 0.5 isn't supported yet, but we also have those caveats listed in the "Try it now" for 0.5 section.

[mrlacey]

Everything in Reunion is included in one framework package and distributed together as one.

@andrewleader will this always be the case?

[dotMorten]

everything is included in one framework package

But it's 4 nuget packages with what seems to be an odd cyclic dependency. Could we get that all cleaned up?
I do also find it weird/odd that dwrite and winui is forced on you, and you can't pick the features you want/need, and considering winui changes how to parse xaml breaks existing WPF projects that wants to use some of the reunion features, by changing how to compile xaml.

[andrewleader]

@mrlacey @dotMorten there is currently no plan to move away from only using one single framework package to distribute all of Project Reunion. And the 4 NuGet packages can't be used independently, it's just an implementation detail that there's 3 sub-packages.

I'd love to know what you ideally would want and why (and WinUI 3 breaking WPF XAML is an example of a bug, not a reason to ship separately). It may be worth one of you creating a new discussion in the Discussions tab to continue discussing this further (rather than taking over this bug's thread). Really appreciate the feedback!