Multiple issues when trying to package .NET 5 WPF project with a Windows Packaging project

[lennartb-]

Hello,

I hope this is the correct project for this problem. We're observing several issues when trying to package a .NET 5 application with a Windows Packaging project. I have build a minimal repro solution which can be found here: https://github.com/lennartb-/WpfMsixDemo

We're using Visual Studio 2019 16.10.0.

The first issues are a warning and and error right off the bat:

MSB4044	The "ProcessFrameworkReferences" task was not given a value for the required parameter "RuntimeGraphPath".	 MsixProject C:\ProgramFiles\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets	63	

This is apparently the same as #17711.

The other error is stranger:

Warning	NU1702	ProjectReference 'C:\Users\lbrue\Source\Repos\WpfMsixDemo\WpfMsixDemo\WpfProject\WpfProject.csproj' was resolved using '.NETCoreApp,Version=v5.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project.	MsixProject	D:\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets	1717	

There are no references at all to 4.5.1, especially since the .wapproj doesn't have a target framework.

When trying to package the WPF project via right click on MsixProject -> Publish -> Create App Packages, and then "Sideloading", skipping signing, and these (default) settings:

We're getting:

Error		It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false.	MsixProject	C:\Program Files\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets	127	

Which seems to be the same as microsoft/MSIX-PackageSupportFramework#151

If I add <RuntimeIdentifiers>win-x64;win-x86</RuntimeIdentifiers> to the WPF project and try to re-publish, I'm getting a different error:

There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Users\lbrue\Source\Repos\WpfMsixDemo\WpfMsixDemo\WpfProject\bin\x86\Debug\net5.0-windows\win-x86\WpfProject.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

Okay, this may have something to do with the fact that .NET5 apparently doesn't have the notion of AnyCPU? So we try to publish explicitly as Debug (x86), this time with a self-signed certificate created in the signing step earlier - this works now as expected. I can install the package via the generated Add-AppDevPackage.ps1 and run the app successfully.

In our actual project, the only configuration that we could run was Release (x86), other architectures would install but not start. In The event log, there were these errors:

Description: A .NET application failed.
Application: Contoso.Ide.Frontend.Wpf.exe
Path: C:\Program Files\WindowsApps\cebbfdbd-a176-41fd-a9ae-886ff49f406d_1.0.0.0_x64__4npsxfd6mepsr\Contoso.Ide.Frontend.Wpf\Contoso.Ide.Frontend.Wpf.exe
Message: Failed to load the dll from [C:\Program Files\WindowsApps\cebbfdbd-a176-41fd-a9ae-886ff49f406d_1.0.0.0_x64__4npsxfd6mepsr\Contoso.Ide.Frontend.Wpf\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\WindowsApps\cebbfdbd-a176-41fd-a9ae-886ff49f406d_1.0.0.0_x64__4npsxfd6mepsr\Contoso.Ide.Frontend.Wpf\hostfxr.dll failed

Application: Contoso.Ide.Frontend.Wpf.exe
CoreCLR Version: 5.0.621.22011
.NET Version: 5.0.6
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitializationException: The type initializer for 'System.Windows.Application' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'System.Windows.Navigation.BaseUriHelper' threw an exception.
 ---> System.TypeInitializationException: The type initializer for 'MS.Internal.TraceDependencyProperty' threw an exception.
 ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (0x8007000B)
   at MS.Internal.AvTrace.IsWpfTracingEnabledInRegistry()
   at MS.Internal.AvTrace.ShouldCreateTraceSources()
   at MS.Internal.AvTrace.Initialize()
   at MS.Internal.AvTrace..ctor(GetTraceSourceDelegate getTraceSourceDelegate, ClearTraceSourceDelegate clearTraceSourceDelegate)
   at MS.Internal.TraceDependencyProperty..cctor()
   --- End of inner exception stack trace ---
   at MS.Internal.TraceDependencyProperty.get_IsEnabled()
   at System.Windows.DependencyProperty.RegisterCommon(String name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata, ValidateValueCallback validateValueCallback)
   at System.Windows.DependencyProperty.RegisterAttached(String name, Type propertyType, Type ownerType, PropertyMetadata defaultMetadata)
   at System.Windows.Navigation.BaseUriHelper..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Navigation.BaseUriHelper.get_PackAppBaseUri()
   at System.Windows.Application.ApplicationInit()
   at System.Windows.Application..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Application..ctor()
   at Contoso.Ide.Frontend.Wpf.App..ctor()
   at Contoso.Ide.Frontend.Wpf.App.Main()

Is packaging a .NET 5 WPF app this way currently supported, or did we try something not yet completely ready?

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[sfoslund]

The first issue appears to have been fixed by #17737, which may not have been released yet. The other issues seem to be related to https://github.com/microsoft/MSIX-PackageSupportFramework so I'm going to transfer this issue there, thanks.

[sfoslund]

This issue was moved to microsoft/MSIX-PackageSupportFramework#180

[lennartb-]

Not denying it has something to do with MSIX, but MSIX-PackageSupportFramework seems to be specifically targeted towards specific fixes for existing MSIX files. I didn't even know about (or downloaded or used) the PSF up until now. Maybe https://github.com/microsoft/msix-packaging would be more fitting?