One of the most annoying “features” of both UWP and WinUI/ProjectReunion WindowsAppSDK apps is the need to generate a package. With UWP development, the packaging was built into the UWP project. However, with the WindowsAppSDK, a separate packaging project is currently required. In this post we’re going to walk through how you can remove this packaging project and instead use the preview of the Single-Project MSIX Packaging Tool.
To begin with, make sure you installed the latest Project Reunion extension (yes, at the time I’m writing this, the extension is still called the Project Reunion extension but I would expect this to change soon to reflect the Windows App SDK naming). Also install, the Single-Project MSIX Packaging Tool extension. Note, you don’t need to install the Project Reunion preview extension in order to follow these steps.
Let’s get started – in this walk through I’m going to create a new application using the Blank App, Packaged (WinUI 3 in Desktop) template.
Before proceeding further, make sure you can build and run the application. Make sure the packaging project is set as the startup project and hit run to build and launch the application. This is an important step – if you can’t get the application to build and run at this point, you’ll just be chasing your tail later on trying to get things to work.
Before we remove the packaging project, there are a couple of things we need to copy into the application project. Select the Images folder and the package.appxmanifest and copy them into the application project. Now you can either unload the packaging project, or remove it completely.
Next, right-click on the Properties folder in the application project and Add a New Item. Add a json file called launchSettings.json and insert the following contents:
{
"profiles": {
"NoPackagingProjectRequired": {
"commandName": "AppContainer"
}
}
}
Replace “NoPackagingProjectRequired” with the name of your application – this is the name of the launch profile; it’s also what appears in the run button in Visual Studio.
At this point if you attempt to run your application you’ll probably see an error stating that “The project doesn’t know how to run the profile…”
Double-click on the application project to open the csproj file. Add the EnablePreviewMsixTooling and WindowsPackageType elements, as shown in the following snippet.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows10.0.19041.0</TargetFramework>
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
<RootNamespace>NoPackagingProjectRequired</RootNamespace>
<ApplicationManifest>app.manifest</ApplicationManifest>
<Platforms>x86;x64;arm64</Platforms>
<RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
<UseWinUI>true</UseWinUI>
<EnablePreviewMsixTooling>true</EnablePreviewMsixTooling>
<WindowsPackageType>MSIX</WindowsPackageType>
</PropertyGroup>
<ItemGroup>
Now if you attempt to run the application, you may still get an error, this time stating that “The project needs to be deployed before we can debug”.
The last step is to set the application project to Deploy. Right-click on the solution node in Solution Explorer and select Configuration Manager. Check the box in the Deploy column for the application project.
And you’re done – you should be able to build, deploy and debug your application, all without the need of a separate packaging project.
Truly awesome. Thank you so much, Nick. I have an issue with the last step though: I cannot check the box in the Deploy column as it is disabled/greyed. Any idea how to fix this? Thanks.
It is OK now. The reason was the new json file was not in the Properties folder.
Hi. Thanks for the article.
I follow your article not in a step-by-step manner, so what it was not obvious to me,
– Install Single-Project MSIX Packaging Tool and why it is needed. So I try to skip
– Once I install, no deployment checkbox appears, until I set AppContainer in the launchSettings.json
By a chance, do you know how I can create AppContainer using MSBuild only? I’m start playing with NativeAOT and WinUI, so need create build process using CLI first. And then run from command line second. Any advice would be welcome.
Right now I would stick with the packaging project – it’s much more stable and complete. You can run packaging the same way as you would for a UWP app I think – it uses makeappx to generate the package.
Dear Nick,
After publishing the app as “Self-contained” and “Produce single file”, when I execute the .exe file, which size is about 124 MB, generated in the “publish” folder, nothing happens, not even in the task manager, even if the Windows 10 version is recent: Build 19042.
Did you manage to run the app (without the MSIX package)? Or maybe I misunderstood the purpose of this post: my initial understanding was that it describes how to create unpackaged apps (even though Microsoft plans to enables this “Project Reunion” feature not before Q4). Is it correct?
And many thanks for your awesome and frequent posts.
More precisely, my context is as follows:
I developed a Uno UWP app weeks ago working nicely with WinUI 2.x controls including 2 ListViews (drag and drop), MenuBar, NumberBox, InfoBar, TeachingTip, MenuFlyout etc. but the fact it is packaged (MSIX) is not accepted by the Team Leader who requires a single .exe file, like for WPF apps. This post gave me hope converting the packaged Uno UWP app to an (unpackaged) WinUI 3 app would fix this issue (unpackaged desktop app keeping the same cool WinUI controls), while being future-proof (.NET 5 and WinUI 3), without having to wait for “Project Reunion” v1.0 in Q4. What is your thought?
The good news is that you’re on the right track. The bad news is that you will need to wait for v1 in order for the unpackaged option to be available for WinUI apps. Check out this link to see the roadmap for various features for unpackaged apps.
I’m guessing that there will be a v1 preview out shortly which you can use to validate the concept (and distribute internally for testing I guess).
What was the reason that the Team Leader requires an exe file? Is it so that it can be copied and run? or is it some misplaced aversion to MSIX?
Many thanks, Nick. Yes indeed, he is used to copy and run desktop apps from a USB stick to some PCs of the organization, as it is for local internal use only. That said, this recent Microsoft tutorial gives me a bit of hope and I will try it today with the experimental release channel of the Windows App SDK, as the new desktop app I developed will not go live before October, then I will let you know the status:
https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-unpackaged-apps
https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/tutorial-unpackaged-deployment?tabs=cpp
https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/experimental-channel
Deployment for unpackaged apps (experimental feature)
This release introduces new experimental deployment features for unpackaged apps (that is, apps that are not deployed in an MSIX package). Unpackaged apps can now dynamically take a dependency on the Windows App SDK runtime packages so you can continue using your existing MSI or setup program for app deployment. This is available through the following features:
– Standalone installer for Windows App SDK.
– MSIX package bundle that includes dynamic dependencies functionality.
For more more information, see Deploy unpackaged apps.
Nick, you were right: unpackaged WinUI 3 apps will not be possible before Q4 with v1.0. Thus I turned my UWP app into a packaged WinUI 3 app for the near future (hopefully it can become unpackaged by October) and then into a WPF for .NET Core 3.1 app with XAML Islands (as it is not working with .NET 5) in order to keep the advantages of the already implemented WinUI 2.x controls (including enhanced ListView, TeachingTip etc.), in case we must go live in September, with x:Bind as the biggest limitation of XAML Islands compared to UWP.
Well, I’ve just found a port of XAML Islands for .NET 5 (so cool):
https://github.com/nesherhh/XamlIslandsNET5