09/04/2017: post updated to include a reference to desktop applications developed with C++, since CPP projects are supported as well by the Desktop Bridge Packaging Project.
Let’s see how to use the Desktop Bridge Packaging Project and how it can make our life much easier.
Installing Visual Studio Preview and packaging a .NET application
The first step is to install Visual Studio 2017 Preview, which you can get from https://www.visualstudio.com/vs/preview/. Make sure to install, as minimum requirement for the purpose of this post:
- The tools for developing Universal Windows Platform apps.
- The tools for developing desktop application based on the .NET Framework (like Windows Forms or WPF) or C++.
Now let’s start by opening your .NET desktop application with Visual Studio 2017 Preview. For the purpose of this post, I’m going to reuse a simple Windows Forms application that I wrote a while ago as a sample for the Convert phase of the Desktop Bridge journey, which you can find on GitHub at https://github.com/qmatteoq/DesktopBridge/tree/master/3.%20Convert/Convert However, the new Desktop Bridge Packaging Project will work with any Windows Forms, WPF project or C++ project. Just remember that, in case you’re using one of the first two technologies, the minimum version of the .NET Framework supported by the Desktop Bridge is 4.0, even if it’s highly recommended to target at least .NET 4.6.1.
The application is very simple. The UI includes two buttons, which both create a text file on the desktop: the only difference is that the first one includes a sample text, the second one saves instead a serialized version of an entity that represents a person by using the popular JSON.NET library. The goal of this second sample was to show how to handle, in a packaged version of a desktop application, a dependency from a 3rd party library. Both operations create the file directly on the desktop of the user, which is a task that a Universal Windows Platform app would need to perform in a different way (for example, by using the FileSavePicker API to ask to the user where he wants to save the file).
Now let’s right click on the Visual Studio solution and choose Add –> New project. In the Universal Windows Platform section, you will find a new template called Desktop Bridge Packaging Project:
Give to the project a meaningful name (I like to use the naming convention <name of the original desktop project>.Package) and press OK. The first thing you will be asked is which version of the Universal Windows Platform SDK you want to target. This choice doesn’t really have a real impact, since we’re talking about a packaged version of a desktop application and not a full Universal Windows Platform app. However, make sure to choose, as Minimum version, at least the 14393 SDK (Anniversary Update), since it’s the first edition of Windows that added support to the Desktop Bridge. If you target a prior version as minimum, you’ll get an error during the first compilation.
This how your solution will look like:
As you can see, the Convert.Package project looks like a Universal Windows Platform one. It has an Assets folder, where the various images for icons and tiles are stored; it has a Package.appxmanifest, which is the manifest file of the application; it has a temporary certificate, which is used to sign the package for testing purposes. However, instead of having a References section with the list of all the libraries used by the application, it has a new section called Applications. Its purpose is exactly to specify which applications should be included in the app package. Right click on it, choose Add reference and you will see a list automatically filtered to display only the other projects that are part of the solution which are full applications and not just libraries. In my case, for example, I’m able to see only the Windows Forms app called Convert, I can’t add a reference to a generic library:
Click on it and you will find the Convert application listed under Applications, like if it’s a normal reference. Now there’s another step to take which is required because, as we have seen in another post on this blog, an app package can contain multiple executables, which can be launched between each other. This is a very important scenario to keep in mind, especially when it comes to Windows 10 S compatibility: a Desktop Bridge app running on Windows 10 S, in fact, can launch another process using the Process.Start() method of the .NET Framework only if it’s part of the same app package. If it’s an external process, you will get an exception and the operation will fail. However, despite an app package can contain multiple executables, it can have only one entry point, which is the process that is launched when the user clicks on the tile or on the icon in the Start menu. As such, by using the Applications section of the Desktop Bridge Packaging Project, we can add a reference to multiple applications, in case our Visual Studio solution contains multiple .NET desktop projects. However, only one of them can be the starting point, which is the one that, if you remember when we had to manually edit the manifest file, was set using the <Application> tag like in the following example:
<Application Id="Convert" Executable="win32\Convert.exe" EntryPoint="Windows.FullTrustApplication">
Thanks to the new Packaging project, we don’t have anymore to manually set the entry point, but it’s enough to right click on the application we want in the Applications section (in my sample, the Convert one) and choose Set as entry point.
- No more manual editing of the manifest file. Out of the box, the included manifest is already tailored for a Desktop Bridge application. You just need to set which is the entry point but, as you have seen, the operation is done with a simple right click.
- Automatic generation of all required assets starting from a single image, thanks to the new tool added in Visual Studio 2017 in the Assets section of the manifest visual editor.
- Generation of the packages (both for the Store and for sideloading) using the Visual Studio wizard (available when you right click on the Desktop Bridge Packaging Project and you choose Store –> Create App Packages), instead of having to deal with command line tools like makeappx or signtool.
- Editing of the information stored in the manifest (like application’s name, capabilities, extensions, etc.) in a visual way, instead of having to manually edit the XML file.
- In case of Store publishing (which, remember, requires first to nominate your application, since your account requires a special capability), you can easily assign an identity to the application from one of the names you have reserved on the Dev Center thanks to the Visual Studio wizard Store –> Associate App with the Store. Previously, you needed to manually copy the required information (like publisher or identity name) from the Dev Center website and paste them inside the XML of the manifest file.
As you have seen, using the Desktop Bridge to package a desktop application based on the .NET Framework is easier than ever. This way, you can take advantage of all the benefits of the Desktop Bridge technology: you can distribute it using the Store or the Store for Business (other than the traditional distribution channels); you can improve the deployment experience; you can start leveraging the benefits of the Universal Windows Platform and plan a migration path without having to immediately rewrite from scratch your existing desktop application. You can download the sample project used in this post from https://github.com/qmatteoq/DesktopBridge/tree/master/Extras/PackagingProject Just remember that, to open it, you need to install Visual Studio 2017 Preview first from https://www.visualstudio.com/vs/preview/. If you’ll try to open it with the regular Visual Studio 2017 version, you will get an error, since the Desktop Bridge Packaging Project won’t be recognized.
And if you’re a Windows developer, don’t miss also another important feature coming with Visual Studio 2017 Update 4: support to .NET Standard Libraries 2.0 in UWP apps built with the upcoming Fall Creators Update SDK. Thanks to this new feature, you’ll be able to leverage lot of highly requested APIs from the .NET Framework also in a UWP application, like DataSet or SqlClient to perform queries directly on a database. You can learn more in the following blog post: https://blogs.msdn.microsoft.com/dotnet/2017/08/25/uwp-net-standard-2-0-preview/https://blogs.msdn.microsoft.com/dotnet/2017/08/25/uwp-net-standard-2-0-preview/