dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
22.22k stars 1.75k forks source link

Unable to deploy WinUI App after updating to 8.0.10, 8.0.14, 8.0.20, or installing VS 17.10 #21744

Closed GXSA-Qi closed 3 months ago

GXSA-Qi commented 7 months ago

Information

It looks like this is a bug in the Windows OS that went out beginning of March related to deploying the WinAppSDK runtime that's packaged with the WinAppSDK nuget. There is a planned OS update in the near future that will resolve this issue.

Workaround

2 available workarounds

  1. Manually install the runtime that corresponds to the version you are using https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads

    • MAUI 8.0.20+ is 1.5.2
    • MAUI 8.0.10-8.0.14 is 1.4.2
  2. Set the project property in your MAUI app project. Ideally workaround 1 works for you. Disabling the DeploymentManager will cause some features of WinUI to no longer work.

    <PropertyGroup>
       <WindowsAppSdkDeploymentManagerInitialize>false</WindowsAppSdkDeploymentManagerInitialize>
    </PropertyGroup>

Description

The program fails to compile after version 8.0.20 of the Microsoft.Maui.Controls and Microsoft.Maui.Controls.Compatibility packages.

Steps to Reproduce

1.Use visual studio 2022 to create a new MAUI project file. 2.Compile and run it on Windows platform, and the program starts normally. image (The Nuget package version used is shown in the figure) image 4.Upgrade the nuget package version to 8.0.20. image 5.Compile the program again and find that the program cannot run normally. image The exception information is as follows: 引发的异常:“System.Runtime.InteropServices.COMException”(位于 WinRT.Runtime.dll 中) WinRT 信息: 找不到元素。

Link to public reproduction project repository

No response

Version with bug

8.0.20 SR4

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

8.0.14 SR3.1

Affected platforms

Windows

Affected platform versions

Windows 11,version 22631.3296

Did you find any workaround?

No response

Relevant log output

No response

PureWeen commented 7 months ago

@GXSA-Qi if you Close VS, delete your bin/obj folder, and then reopen the project does it work?

GXSA-Qi commented 7 months ago

@GXSA-Qi if you Close VS, delete your bin/obj folder, and then reopen the project does it work?

Nope, Even deleting the bin and obj folders does not solve the problem. Here is a video demonstrating these operations:

https://github.com/dotnet/maui/assets/63104968/bfdbba9e-8a5e-4365-b431-93fec611cc3a

MartinRothschink commented 7 months ago

I have the exact same issue on multiple projects. 8.014 is fine, 8.0.20 crashes.

Contrary to the issue title, the compile works fine, the app crashes on start.

Event log shows this error for a release build:

CoreCLR Version: 8.0.424.16909
.NET Version: 8.0.4
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitializationException: The type initializer for '<Module>' threw an exception.
 ---> System.Runtime.InteropServices.COMException (0x80070490): Element nicht gefunden.

Element nicht gefunden.

   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|39_0(Int32 hr)
   at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
   at ABI.Microsoft.Windows.ApplicationModel.WindowsAppRuntime.IDeploymentManagerStatics2Methods.Initialize(IObjectReference _obj, DeploymentInitializeOptions deploymentInitializeOptions)
   at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManager.Initialize(DeploymentInitializeOptions deploymentInitializeOptions)
   at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize.AccessWindowsAppSDK()
   at .cctor()
   --- End of inner exception stack trace ---
Yannikk1996 commented 7 months ago

Same issue here. The app crashes on start with 8.0.20.

GXSA-Qi commented 7 months ago

I have the exact same issue on multiple projects. 8.014 is fine, 8.0.20 crashes.

Contrary to the issue title, the compile works fine, the app crashes on start.

Event log shows this error for a release build:

CoreCLR Version: 8.0.424.16909 .NET Version: 8.0.4 Description: The process was terminated due to an unhandled exception. Exception Info: System.TypeInitializationException: The type initializer for '' threw an exception. ---> System.Runtime.InteropServices.COMException (0x80070490): Element nicht gefunden.

Element nicht gefunden.

at WinRT.ExceptionHelpers.g__Throw|39_0(Int32 hr) at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr) at ABI.Microsoft.Windows.ApplicationModel.WindowsAppRuntime.IDeploymentManagerStatics2Methods.Initialize(IObjectReference _obj, DeploymentInitializeOptions deploymentInitializeOptions) at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManager.Initialize(DeploymentInitializeOptions deploymentInitializeOptions) at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize.AccessWindowsAppSDK() at .cctor() --- End of inner exception stack trace ---

Maybe there is something wrong with what I have described, (the translator cannot accurately express my meaning) you are right 😂, the compilation is not a problem, the problem is the program running.

mattleibow commented 7 months ago

There may be an issue in Windows App SDK 1.5, so you can do either of these 2 things for now:

Help us debug the issue

1) get the output of get-appxpackage micro*win*app*run* -allusers from running powershell in admin mode. This will help us determine the root cause.

More info here: https://github.com/microsoft/WindowsAppSDK/issues/4268#issuecomment-2016009529

2) try installing he latest WASDK that just went out today: https://www.nuget.org/packages/Microsoft.WindowsAppSDK/1.5.240404000

Possible workarounds

  1. Manually install the runtime with the Windows App SDK Runtime Installer x64
  2. Set the project property in your MAUI app project:
    <PropertyGroup>
       <WindowsAppSdkDeploymentManagerInitialize>false</WindowsAppSdkDeploymentManagerInitialize>
    </PropertyGroup>
PureWeen commented 7 months ago

related https://github.com/microsoft/WindowsAppSDK/issues/4268 https://github.com/marticliment/WingetUI/issues/1939

bmacombe commented 7 months ago

There may be an issue in Windows App SDK 1.5, so you can do either of these 2 things for now:

  1. Manually install the runtime with the Windows App SDK Runtime Installer x64
  2. Set the project property in your MAUI app project:
    <PropertyGroup>
       <WindowsAppSdkDeploymentManagerInitialize>false</WindowsAppSdkDeploymentManagerInitialize>
    </PropertyGroup>

I tried option 2 on a reproduction I was setting up when I thought this was an issue in SyncFusion 25.1.39, I could deploy and debug WinUI after adding that to project

PureWeen commented 7 months ago

There may be an issue in Windows App SDK 1.5, so you can do either of these 2 things for now:

  1. Manually install the runtime with the Windows App SDK Runtime Installer x64
  2. Set the project property in your MAUI app project:
    <PropertyGroup>
       <WindowsAppSdkDeploymentManagerInitialize>false</WindowsAppSdkDeploymentManagerInitialize>
    </PropertyGroup>

I tried option 2 on a reproduction I was setting up when I thought this was an issue in SyncFusion 25.1.39, I could deploy and debug WinUI after adding that to project

Can you run this command on powershell in admin mode?

Get-AppxPackage -allusers WinAppRuntime

bmacombe commented 7 months ago

@PureWeen I ran that command and then I assume I should try the project again without the WindowsAppSdkDeploymentManagerInitialize set to false.

I did that and still got the app crash on startup.

Edit, oh I see you are expecting output from the Get-AppxPackage -allusers WinAppRuntime command. I'm getting nothing out of it.

image

bmacombe commented 7 months ago

I ran the command referenced in the WindowsAppSDK issue

powershell -c Get-AppxPackage microwinapprun -AllUsers

Output attached Output.txt

GXSA-Qi commented 7 months ago

There may be an issue in Windows App SDK 1.5, so you can do either of these 2 things for now:

Help us debug the issue

  1. get the output of get-appxpackage micro*win*app*run* -allusers from running powershell in admin mode. This will help us determine the root cause.

More info here: microsoft/WindowsAppSDK#4268 (comment)

  1. try installing he latest WASDK that just went out today: https://www.nuget.org/packages/Microsoft.WindowsAppSDK/1.5.240404000

Possible workarounds

  1. Manually install the runtime with the Windows App SDK Runtime Installer x64
  2. Set the project property in your MAUI app project:
    <PropertyGroup>
       <WindowsAppSdkDeploymentManagerInitialize>false</WindowsAppSdkDeploymentManagerInitialize>
    </PropertyGroup>

After installing the Windows App SDK Runtime Installer x64 installation package, the project using version 8.0.20nuget package was able to run normally after compilation. I also tried to package it and found that the Dependencies directory was Microsoft. Windows App Runtime. 1.5. msix, while versions 8.0.14 and earlier were Microsoft. Windows App Runtime. 1.4. msix. It is indeed caused by inconsistent versions of Windows App runtime.

GXSA-Qi commented 7 months ago

There may be an issue in Windows App SDK 1.5, so you can do either of these 2 things for now:

Help us debug the issue

  1. get the output of get-appxpackage micro*win*app*run* -allusers from running powershell in admin mode. This will help us determine the root cause.

More info here: microsoft/WindowsAppSDK#4268 (comment)

  1. try installing he latest WASDK that just went out today: https://www.nuget.org/packages/Microsoft.WindowsAppSDK/1.5.240404000

Possible workarounds

  1. Manually install the runtime with the Windows App SDK Runtime Installer x64
  2. Set the project property in your MAUI app project:
    <PropertyGroup>
       <WindowsAppSdkDeploymentManagerInitialize>false</WindowsAppSdkDeploymentManagerInitialize>
    </PropertyGroup>

After installing the Windows App SDK Runtime Installer x64 installation package, the project using version 8.0.20nuget package was able to run normally after compilation. I also tried to package it and found that the Dependencies directory was Microsoft. Windows App Runtime. 1.5. msix, while versions 8.0.14 and earlier were Microsoft. Windows App Runtime. 1.4. msix. It is indeed caused by inconsistent versions of Windows App runtime.

This is a screenshot: image

kevinxufei commented 7 months ago

Can repro this issue at Windows platform on the latest 17.10.0 Preview 3 (8.0.20), but not repro on 8.0.14/8.0.10

bmacombe commented 7 months ago

I can deploy and run on Windows fine with 8.0.20 on my desktop machine, but not the laptop I was using yesterday. So definitely an environment issue, both machines have VS 17.9.6. The only known difference I can think of between the two machines is the laptop has an insider build of Win 11 23H2 (22635.3430) and the desktop is on 23H2 (22631.3447). Not saying that is the issue, only trying to think of anything that would be different.

CloudKlan commented 7 months ago

Same here, the build is fine, but for the app to run properly, the only thing working around is to add the WindowsAppSdkDeploymentManagerInitialize property to the .csproj

appxpackage_output.txt

mattleibow commented 7 months ago

After some back and forth with various teams, it appears there is some type of corruption happening to the install state of some parts of Windows App SDK. Investigation is ongoing, but this is affecting many teams.

We are not sure yet what and how things are breaking, but for some reason the installation of the 1.5 satellite packages is causing bad things to happen. Luckily, this only affects the satellite packages which are not really used by most apps. So using the WindowsAppSdkDeploymentManagerInitialize workaround is the best way forward.

I believe there are a few features that require the deployment manager - or rather they require the packages that the deployment manager installs. I think there was some integration with notifications. However, once the OS/Store installs those packages, the deployment manager is basically a no-op.

So, for now, disabling the deployment manager is the best option if you are not using a feature that requires it.

PureWeen commented 6 months ago

I'm backlogging this issue because it's a Windows OS issue (see updated description)

mattleibow commented 5 months ago

For future us to find the OS issues:

jeremy-bridges commented 4 months ago

For future us to find the OS issues:

* https://dev.azure.com/microsoft/OS/_workitems/edit/50160968

* https://dev.azure.com/microsoft/OS/_workitems/edit/49055767

I cannot get to these work items.

PureWeen commented 3 months ago

The latest version of Windows has patched this, so, I'm going to close this issue.