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

4. Compile
5. 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.

<SDKIdentifier>Windows</SDKIdentifier>
<SDKVersion>10.0</SDKVersion>

[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!

[huichen123]

Fixed in next servicing release (also include changes in internal repo).

[dotMorten]

@andrewleader If I'm building a WPF app and want to use MRTCore, I automatically get all the WinUI APIs. Which means I now have several duplicate classes (in different namespaces), and it gets confusing to constantly trying to resolve a class name and picking the right namespace. I'd never want to resolve to a WinUI or WinRT class, so it's better if I can avoid just referencing that assembly completely, as I would never ever use it. I get you're saying the package gets installed anyway, and that's fine, but I don't want it referenced in my project to keep things clean and easy to work with.

It's also about telling a clean story with any class libraries we build - my class library could clearly state that it takes just a dependency on MRTCore, and doesn't depend on any WinUI components, but is completely stand-alone.

[andrewleader]

Servicing release 0.5.5 that fixes this issue is available now @dotMorten! You should be able to use Project Reunion non-WinUI features in your WPF MSIX .NET 5 apps now! (yes, you still have to reference the entire Project Reunion - separate topic).

[dotMorten]

@andrewleader Yup! Compiles now. Still hitting a few issues though trying to use the resource manager (and it only returns the resources from the package project and not the app), but closer at least :-)

            Microsoft.ApplicationModel.Resources.ResourceManager rm
                = new Microsoft.ApplicationModel.Resources.ResourceManager();
            for(uint i = 0;i< rm.MainResourceMap.ResourceCount; i++)
            {
                var value = rm.MainResourceMap.GetValueByIndex(i);
            }
            var val = rm.MainResourceMap.GetValue(@"Files/Images/LockScreenLogo.png");
            byte[] bytes = val.ValueAsBytes; // Crashes !
            var qualifiers = val.QualifierValues.ToArray(); // Crashes !

[huichen123]

@dotMorten in your csproj, you need to switch the PackageReference from "Microsoft.ProjectReunion.Foundation" to "Microsoft.ProjectReunion". In your wapproj, also add a PackageReferene to "Microsoft.ProjectReunion".

[dotMorten]

@huichen123 Yes I already did that

[huichen123]

@dotMorten i c. unless you embedded the png in PRI file, you will get a file path, thus you need to use ValueAsString to get the path instead of ValueAsBytes.

[dotMorten]

@huichen123 Got it! Works great:

The crash is pretty unhelpful though. Would be nice getting an error that actually told me what I did wrong:

[huichen123]

the hresult it throws is 0x80073b0d, which is ERROR_MRM_RESOURCE_TYPE_MISMATCH. hopefully that gives you some clue.