Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sfoslund opened this issue Jun 2, 2021 · 3 comments

Comments

@sfoslund
Copy link
Member

sfoslund commented Jun 2, 2021


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 #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
Copy link
Member Author

sfoslund commented Jun 2, 2021


Issue moved from dotnet/sdk#18031

  • Please respond to @dotnet-issue-labeler[bot].

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
Copy link
Member Author

sfoslund commented Jun 2, 2021


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 dotnet/sdk#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
Copy link
Contributor

dhoehna commented Jun 17, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants