WindowsAppSDK: WPF doesn't compile with ProjectReunion
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
- Create a WPF .NET 5 project. csproj:
- Add the Foundation Package.
- 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
- Compile
- 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 <UsingTask> 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
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (18 by maintainers)
@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.
unfortunately there is no ala carte support at this moment. maybe remove WinUI from microsoft.projectreunion.nuspec in the nuget cache.
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.)Fixed in next servicing release (also include changes in internal repo).
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.
@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!
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.