search

microsoft / MSIX-PackageSupportFramework

The Package Support Framework (PSF) is a kit for applying compatibility fixes to packaged desktop applications.
MIT License
114 stars 57 forks source link

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

Open sfoslund opened 3 years ago

sfoslund commented 3 years ago

Issue moved from dotnet/sdk#18031

From @lennartb- on Wednesday, June 2, 2021 6:26:20 AM

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:

image

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 https://github.com/microsoft/MSIX-PackageSupportFramework/issues/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?

sfoslund commented 3 years ago

Issue moved from dotnet/sdk#18031

From @dotnet-issue-labeler[bot] on Wednesday, June 2, 2021 6:26:23 AM

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 commented 3 years ago

Issue moved from dotnet/sdk#18031

From @sfoslund on Wednesday, June 2, 2021 10:13:20 PM

The first issue appears to have been fixed by https://github.com/dotnet/sdk/pull/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.

dhoehna commented 3 years ago

Hey @sfoslund. I understand the frustration of multiple error messages that all make no sense.

The Visual Studio team released a fix on 06/16 with VS version 16.10.2. I was able to use the Desktop Bridge to package a WPF application with AnyCPU.

Can you please try your example again, but with the newest VS version?