.NET MAUI Windows target publishing/archiving

TL;DR

• Publishing a .NET MAUI Windows app (both .NET MAUI and .NET MAUI Blazor) to an msix works, see bullet 4 below
  • Running it on a non-dev machine seems to work fine for a regular .NET MAUI app, but not for a .NET MAUI Blazor app
• Publishing to an exe (not self-contained) works but don’t take the published folder files, take the build artifacts, see bullet 3 below for all the details
• Self-contained/sideloaded apps do not seem to work in any variation at this time
• This is all through the command-line, UI support in Visual Studio is not there (yet)

Description

I have been trying to see if publishing a Windows app through .NET MAUI works at the moment. There are a few different variations, most don’t work, but I have been able to produce a working msix file.

Ideally I would think dotnet publish would be supported. However if we look at the csproj file we see that we need MSBuildRuntimeType == full. So the only way to achieve anything right now is by using msbuild.

Disclaimer: my knowledge on Windows apps isn’t all that great, so there might be things in here that don’t even make sense in this context. I found some options through ~Google~ Bing and decided to try them out, here are the results.

Questions

• Option 4 seems to work. Is this the expected way? Apart from not having a nice UI to do this from.
  • Can we also create packages to publish to the store this way?
• Should there be a way to just distribute the exe as a single file?
  • Is that supported? If not, will that be supported?
• I’ve also been seeing appx being mentioned. Is that the “old” msix? Or should we somehow also be able to produce appx files?

Background

1. Basic command (doesn’t work)

msbuild_basic.binlog.zip

The most obvious command then is msbuild /restore /t:Publish /p:TargetFramework=net6.0-windows10.0.19041 /p:configuration=release. This completes successfully, however the resulting published app won’t work. You can double-click the main exe, but nothing comes up. Also, the build artifacts in the release folder show the same behavior (why that is important we will see later).

In the Windows Event Viewer, I see this entry after I tried to start the app:

Application: MauiApp23.exe
CoreCLR Version: 6.0.121.56705
.NET Version: 6.0.1
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException: Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
   at MauiApp23.WinUI.Program.XamlCheckProcessRequirements()
   at MauiApp23.WinUI.Program.Main(String[] args) in C:\Users\joverslu\source\repos\MauiApp23\MauiApp23\obj\Release\net6.0-windows10.0.19041\win10-x64\Platforms\Windows\App.g.i.cs:line 28

Sure enough the mentioned DLL Microsoft.ui.xaml.dll is not present amongst the huge amount of files both in the build artifacts and the publish folder.

2. Adding -p:PublishSingleFile=true (doesn’t work)

msbuild_singlefile.binlog.zip

Command: msbuild /restore /t:Publish /p:TargetFramework=net6.0-windows10.0.19041 /p:configuration=release -p:PublishSingleFile=true

With this command the publish folder only contains a couple of files, which I guess makes sense. The build artifacts still is a huge list of files. However, running still results in nothing happening. The Event Viewer shows a somewhat similar entry, but lacks the Microsoft.ui.xaml.dll filename this time.

Application: MauiApp23.exe
CoreCLR Version: 6.0.121.56705
.NET Version: 6.0.1
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException: Dll was not found.
   at MauiApp23.WinUI.Program.XamlCheckProcessRequirements()
   at MauiApp23.WinUI.Program.Main(String[] args) in C:\Users\joverslu\source\repos\MauiApp23\MauiApp23\obj\Release\net6.0-windows10.0.19041\win10-x64\Platforms\Windows\App.g.i.cs:line 28

3. Adding -p:WindowsAppSDKSelfContained=true (somewhat works)

msbuild_windowsappsdk.binlog.zip

Command: msbuild /restore /t:Publish /p:TargetFramework=net6.0-windows10.0.19041 /p:configuration=release -p:WindowsAppSDKSelfContained=true /p:Platform=x64

Then I somewhere found the WindowsAppSDKSelfContained option and decided to try that. Initially it fails, because it seems this option does not support AnyCPU: The platform 'AnyCPU' is not supported for SelfContained mode.

I added the x64 platform through the Visual Studio Configuration Manager Then adding the /p:Platform=x64 option made it complete successfully.

Here is where things get interesting. There are now a big number of files in the publish folder, but running the exe still does not work. There is an event logged in the Event Viewer identical to option 1.

However! If I now navigate up a folder and just look at the build artifacts and run the exe there, it works! The difference seems to be that there are a number of files in the build artifacts that don’t end up in the publish folder. Running a compare between the two folders, these are the files that seem to be different:

	            	C:\Users\joverslu\source\repos\MauiApp23\MauiApp23\bin\x64\Release\net6.0-windows10.0.19041\win10-x64\
	    New File  			AppxManifest.xml
	    New File  			CoreMessagingXP.dll
	    New File  			dcompi.dll
	    New File  			dwmcorei.dll
	    New File  			DwmSceneI.dll
	    New File  			DWriteCore.dll
	    New File  			marshal.dll
	    New File  			MauiApp23.build.appxrecipe
	    New File  			Microsoft.DirectManipulation.dll
	    New File  			Microsoft.InputStateManager.dll
	    New File  			Microsoft.Internal.FrameworkUdk.dll
	    New File  			Microsoft.UI.Composition.OSSupport.dll
	    New File  			Microsoft.UI.Input.dll
	    New File  			Microsoft.UI.Text.winmd
	    New File  			Microsoft.UI.Windowing.Core.dll
	    New File  			Microsoft.UI.Xaml.Controls.dll
	    New File  			Microsoft.UI.Xaml.Controls.pri
	    New File  			Microsoft.ui.xaml.dll
	    New File  			Microsoft.UI.Xaml.Internal.dll
	    New File  			Microsoft.UI.Xaml.Phone.dll
	    New File  			Microsoft.ui.xaml.resources.19h1.dll
	    New File  			Microsoft.ui.xaml.resources.common.dll
	    New File  			Microsoft.UI.Xaml.winmd
	    New File  			Microsoft.Web.WebView2.Core.dll
	    New File  			Microsoft.Web.WebView2.Core.winmd
	    New File  			Microsoft.Windows.ApplicationModel.DynamicDependency.winmd
	    New File  			Microsoft.Windows.ApplicationModel.Resources.dll
	    New File  			Microsoft.Windows.ApplicationModel.Resources.winmd
	    New File  			Microsoft.Windows.ApplicationModel.WindowsAppRuntime.winmd
	    New File  			Microsoft.Windows.AppLifecycle.winmd
	    New File  			Microsoft.Windows.System.Power.winmd
	    Older     			Microsoft.WindowsAppRuntime.Bootstrap.dll
	    New File  			Microsoft.WindowsAppRuntime.dll
	    New File  			Microsoft.WindowsAppRuntime.Insights.Resource.dll
	    New File  			MRM.dll
	    New File  			WinUIEdit.dll
	    New File  			wuceffectsi.dll

When this option is combined with the -p:PublishSingleFile=true we get a singe file in the publish folder which won’t run, however if we copy it back to the build artifacts folder that also runs. So it would seem that the DLLs it’s missing also don’t end up in the single file.

Another weird thing with this option is; the app runs, but I can’t move the window! You can resize the window, but you can’t move it for whatever reason.

4. Adding /p:GenerateAppxPackageOnBuild=true (WORKS!)

Command: msbuild /restore /t:Publish /p:TargetFramework=net6.0-windows10.0.19041 /p:configuration=release /p:GenerateAppxPackageOnBuild=true /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="{your thumbprint}" /p:PackageCe
rtificatePassword="{your password}" (also tried /t:Build)

This generates some files in the AppPackages folder that wasn’t there before which contains an msix file. That won’t let me install because of a certificate error it seems.

I went to find how I should sign my msix file and found that I had to create a self-signed certificate and then I could add a couple of extra parameters to also add the sign the MSIX and then trust that cert manually… AND IT WORKS!

We now have an msix file that can install/update/run the app 🎉

Other

• I have also tried the /p:SelfContained=true option which doesn’t seem to have any influence. I also tried different variations of all the options above, but none of them seemed to work.
• I have tried doing a right-click > Publish which I got somewhat to work, but seems not fully prepared for this scenario just yet. So I am assuming that Visual Studio does not support this scenario in any way right now and all needs to be done through the command-line.
• I needed to manually edit the Package.appxmanifest file because double-clicking it would give me an error (see below). For a regular UWP app, the editor opens and works fine.

Related Resources

• https://docs.microsoft.com/windows/msix/package/create-certificate-package-signing
• https://damienaicheh.github.io/uwp/azure/devops/appcenter/2019/09/24/build-sign-and-deploy-your-uwp-application-using-azure-devops-and-appcenter-en.html
• https://docs.microsoft.com/windows/msix/overview
• https://docs.microsoft.com/windows/apps/windows-app-sdk/single-project-msix
• https://docs.microsoft.com/visualstudio/ide/how-to-create-and-edit-configurations?view=vs-2022

Also See

• #4377
• #4397
• #5399

[Sweekriti91]

Adding this here, we had to figure this out as well, and this is the gist of how I setup the GitHub Actions pipeline : https://gist.github.com/Sweekriti91/75d019ea832e800aee860e54fe7da7c5

[mattleibow]

The fastlink error is because I think we are missing some msvc dependency or runtime. Try installing the uwp workload.

It is this one https://microsoft.visualstudio.com/OS/_workitems/edit/36792859

I believe there is a fix somewhere near.