WinUI 3.0 and C# Examples
Launching Your Apps Outside Microsoft Store
June 16th, 2023
Packaged WinUI apps are typically designed to run through the Microsoft Store, providing a seamless installation and update experience. However, there are situations where you may need to distribute your WinUI app outside of the store, such as sharing it with friends or deploying it to specific machines. Let's see what it takes to build your WinUI app in Visual Studio as a standalone package that can be easily shared and run on different Windows devices.
You have to start your project as a Packaged App. But that doesn't mean that we have to build it as such. When you are selecting how you want to build your app, you go to the dropdown menu and select the Unpackaged version instead.
Of course, then you have to manually manage the dependencies. If your app requires DLL files, you need to make sure that they're in the app folder. Additionally, you'll want to go to the Project File and add a couple of things.
The Project File is an XML document that includes important information about your project, such as references to required libraries, compiler options, build configurations, project dependencies, and more. We're expecially interested in throwing a few options inside the topmost PropertyGroup.
<PropertyGroup>
...
<WindowsPackageType>None</WindowsPackageType>
</PropertyGroup>When we set the WindowsPackageType to None, it indicates that the project is an unpackaged app. This means that the app will not be packaged as an MSIX package for deployment. Instead, it can be run directly from its build output folder without the need for packaging and installation. So, if you don't want to use the Microsoft Store and prefer to distribute your app through other channels, such as direct downloads or side-loading, you can choose to create an unpackaged app.
Another problem, however, might be figuring out how to distribute your application so that it can find the Windows App Runtime.
If you get a warning saying, "This application could not be started. This application requires the Windows App Runtime Version 1.2 (MSIX package version >= 2000.777.2143.0) Do you want to install a compatible Windows App Runtime now?" and notice that no amount of downloading and installing the Windows App Runtimes makes it go away, you may have to resort to drastic measures.
<PropertyGroup>
...
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
</PropertyGroup>See, if you use WindowsPackageType as None without setting WindowsAppSDKSelfContained to true, the project will default to Win32 bootstrapping, which uses Windows App SDK Dynamic Dependency polyfill.
Imagine you have an application that relies on certain capabilities or APIs provided by the Windows App SDK to perform certain tasks or access specific resources. Normally, for the application to work correctly, the user would need to have the Windows App SDK installed on their device. However, with the "Dynamic Dependency polyfill" feature, the application can be designed in such a way that it can run even if the Windows App SDK is not present on the user's device. The polyfill acts as a substitute or replacement for the missing SDK, providing the necessary functionalities or APIs that the application expects.
Think of it as a way for the application to adapt and still function properly in scenarios where the required SDK is not available. The polyfill fills in the gaps, allowing the application to continue working by providing alternative implementations or methods for the SDK's functionalities. This feature can be useful in situations where you want your application to have broader compatibility across different devices or platforms. It allows you to develop your application with the Windows App SDK in mind but still ensure that it can run on devices that may not have the SDK installed. By using the Dynamic Dependency polyfill, developers can create applications that are more flexible and have a wider reach, enabling them to deliver their software to a larger audience without requiring specific dependencies to be installed on each user's device.
When we set the WindowsAppSDKSelfContained to true, it indicates that the Windows App SDK components required by your app are included within the deployment package, ensuring that your app can run independently on the target device without relying on the presence of the Windows App SDK installed separately. This means that all the necessary Windows App SDK files and dependencies will be included within your app's deployment package. It's important to note that including the Windows App SDK as self-contained will increase the size of your app's deployment package significantly. Including it in an empty project increased the size by about 200 Megabytes.
But now the project will run, if you open the EXE file in the Debug or Release folder, and that's something.
