microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.84k stars 320 forks source link

Unable to create a runnable msixbundle #4577

Open boergegrunicke opened 4 months ago

boergegrunicke commented 4 months ago

Describe the bug

Creating a new project with from template in Visual Studio and publishing them to msixbundle only produces crashing output but nothing working

Steps to reproduce the bug

  1. Open Visual Studio and create a new project
  2. Select blank app with windows application packaging project (WinUI 3 in Desktop)
  3. Give it a name and create it (target and minimum version seem not really to matter)
  4. Run it (it will run properly)
  5. Right-click the packaging project -> Publish -> Create App Packages ... -> Sideloading -> Select a vertificate -> Create!
  6. it will fail "The specified RuntimeIdentifier is not recognized" -> okay by removing all win10-xxx runtime identifiers and only keeping the win-xxx identifiers this will work.
  7. Jump to the output folder and install the msixbundle.
  8. Try to launch the app from the start menu -> Nothing will happen
  9. Check the system event log. There is an error containing a hint to C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.5_5001.178.1908.0_x64__8wekyb3d8bbwe\Microsoft.ui.xaml.dll#
  10. By setting PublishTrimmed to false and PublishReadyToRun to True in the publish profile as well as WindowsAppSDKSelfContained to True in the csproj and wapproj this can be solved
  11. Publish again and install it: Now it will crash again:
    Application: App.exe
    CoreCLR Version: 8.0.724.31311
    .NET Version: 8.0.7
    Description: The process was terminated due to an unhandled exception.
    Exception Info: System.TypeInitializationException: The type initializer for '<Module>' threw an exception.
    ---> System.MissingMethodException: Method not found: 'Void System.Environment.SetEnvironmentVariable(System.String, System.String)'.
    at Microsoft.Windows.Foundation.UndockedRegFreeWinRTCS.AutoInitialize.AccessWindowsAppSDK()
    --- End of inner exception stack trace ---

Expected behavior

Creating an app package should produce something that contains all necessary references will start without a crash, or there should be at least a guide somewhere how to get it running

Screenshots

No response

NuGet package version

Windows App SDK 1.5.5: 1.5.240627000

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

Scottj1s commented 3 months ago

@boergegrunicke Thanks for reporting this issue. I suspect the problem lies here:

  1. Jump to the output folder and install the msixbundle.

The .\Dependencies folder (which contains the Windows App Runtime framework packages) must also be installed. The Install.ps1 script generated by Visual Studio takes care of this, whereas just double clicking the msixbundle (or msix) does not.

boergegrunicke commented 3 months ago

@Scottj1s Thanks for the response, actually I was using all the time the Add-AppDevPackage.ps1 script to install the package because this was mentioned in one of the tutorial pages for creating WinUI3-Apps. I double-checked it now with the Install.ps1 script instead, the error is the same, so I assume that cannot be the cause of the problem.

Scottj1s commented 3 months ago

@boergegrunicke Thanks for clarifying. Looking again at your repro steps, I missed this:

  1. By setting PublishTrimmed to false and PublishReadyToRun to True in the publish profile as well as WindowsAppSDKSelfContained to True in the csproj and wapproj this can be solved

I interpret this as saying you can work around the crash with step 10. Is that correct? If so, I think you're encountering the trimming issue described here, which also links to a couple workarounds: https://github.com/microsoft/microsoft-ui-xaml/issues/9740

boergegrunicke commented 3 months ago

@Scottj1s Thanks for taking care. By setting the described Flags from Step 10, I can work around the crash from step 9, what finally leads to the crash described after Step 11. During the last couple of days, I figured out, that this crash does not happen, in case the msixbundle contains only a x64 msix. With this finding, I tried to apply the same to my main application project, this lead to the next crash: Either the <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> propertiy is set true (like it should be) for the main application csproj and the wapproj packaging project. in this case, the compilation fails with

Found multiple publish output files with the same relative path: <ProjectFolder>\obj\x64\Release\net8.0-windows10.0.19041.0\win-x64\MsixContent\Microsoft.WebView2.Core.dll, obj\x64\Release\net8.0-windows10.0.19041.0\win-x64\R2R\Microsoft.WebView2.Core.dll

Or if I set the WindowsAppSDKSelfContained to true only for the wapproj (and not the main app csproj-file), the bundle is built successfully, but after installation it again crashes. In this case, I can find in the system event monitor

Windows App Runtime
ERROR 0x80070032: Bootstrapper initialization failed while looking for version 1.5 (MSIX package version >= 5001.178.1908.0) 
Scottj1s commented 3 months ago

@boergegrunicke Thanks for the clarification. You describe two subsequent issues:

  1. Found multiple publish output files with the same relative path: ...\Microsoft.WebView2.Core.dll This may be due to stale build artifacts following an upgrade to Windows App SDK 1.6. In 1.6, WebView2 code has been factored out and WinAppSDK now just carries a reference to the public WebView2 nuget package. You don't mention upgrading, but you might still try deleting your obj and bin folders to ensure a clean rebuild (specifically, the MsixContent and Manifests folders should be purged).

  2. Windows App Runtime ERROR 0x8007003 ... The bootstrapper should normally only be invoked for an unpackaged configuration (WindowsPackageType=None). You don't mention that here, but if you've made that change you'll need to run the Windows App Runtime installer.

Feel free to provide a self-contained repro project if that's easier.

boergegrunicke commented 3 months ago

Hi @Scottj1s, thanks for your effort. Regarding the two points: I am not using an experimental Version of the App SDK, I am still on Version 1.5.5 (1.5.240627000). Upgrading to the latest experimental Version is blocked by nuget. But in two of my subprojects I have the reference to the "Microsoft.Web.WebView2" package, as I need it for some modules. To the second point: As I described, I am running a project with a separate package creation project. In this combination, as I understood, the application package always is treated as unpackaged. However, the runtime is installed on my machine and if I run it from Visual Studio, it works. The described crash only happens after installing the package

Scottj1s commented 3 months ago

You're welcome!

The scenario of Windows App SDK 1.5 or older, which embeds WebView2, combined with the public WebView2 nuget package (or a project that transitively references it), is not supported. This is the reason for the decision to factor WebView2 out in Windows App SDK 1.6. That said, I see that one of the colliding paths is R2R (ReadyToRun compilation). You could try disabling that (PublishReadyToRun=false) to see if it helps.

The use of a wapproj (Windows Application Packaging project) does produce a packaged, not unpackaged, application. This is independent of how the Windows App Runtime binaries are deployed and consumed, which could be via the Windows App Runtime framework package or via self-contained (WindowsAppSDKSelfContained=true).

At this point, I'd recommend sharing a repro project for us.

boergegrunicke commented 1 month ago

Hi @Scottj1s, as Version 1.6 of the WindowsAppSDK is available as stable release, I started checking the current situation again. I created a fresh solution containing a WinUI3 project with a separate packaging project (WindowsAppSDK version 1.6.240923002) and added another class library that has its own reference to the Microsoft.Web.WebView2 (Version 1.0.2792.45) package and tried to launch this from the main application. Already while building it fails with error code APPX1111 Payload contains two or more files with the same destintation path 'Microsoft.Web.WebView2.Core.dll', but they are different sizes.. As far as I understood it, the 1.6 version of the WindowsAppSDK should support externally added Web View packages. When I manually delete the dll from the bin folder, the build process works, but the application crashes as soon as the library is invoked, complaining that the Microsoft.Web.WebView2.Core.dll cannot be found.

Scottj1s commented 1 week ago

@boergegrunicke Thanks for the update. If possible, a repro project that demonstrates the latest issue, against the latest version of WinAppSDK, would be ideal. There is an issue with the Microsoft.Web.WebView2 nuget package causing APPX1101 error (duplicate payload), which should be addressed this month (in the November update to the Microsoft.Web.WebView2 nuget package)