October 18, 2017 11:00 am

Visual Studio 2017 Update 4 makes it easy to modernize your desktop application and make it store ready

By / Principal Program Manager Lead

Last year with the Windows 10 Anniversary Update, we introduced the Desktop Bridge to provide desktop applications a path to modernize with the Universal Windows Platform, and to distribute via the Windows Store and the Microsoft Store for Business to all Windows 10 PCs, including devices that are running the Windows 10 S configuration.

The primary developer tool at the time was the Desktop App Converter, a tool that converts your current app installer into a Windows app package (.appx file), which can be submitted to the Windows Store or deployed via your distribution mechanism of choice. With Update 4 for Visual Studio 2017 we now have great support directly in Visual Studio for your Windows desktop application projects (WPF, Winforms, Win32, etc.). With the new tools you can now build, configure, deploy, test and debug your Desktop Bridge application as you develop them in VS by simply hitting F5!

Let me walk you through an example, step-by-step. I am starting out with this Winforms app that showcases various chart controls. It’s been created several years ago in an older version of VS against .NET 4. Now my goal is to release it in the Windows Store and incrementally modernize it. Here is how easy it is now with Update 4 for Visual Studio 2017.

Step 1 – Add Windows App Packaging project to the solution

Before we start we need to make sure our desktop application project is loaded in Visual Studio 2017 and builds without error. Then in the next step we want to package our application as a Windows App Package (.appx file) so our Winforms app can take advantage of all the same Windows 10 app deployment features that are available to UWP apps: clean install & uninstall, seamless updates, Store distribution and many more. To do this, we will take advantage of the new tooling features introduced in Update 4 for Visual Studio 2017. We are adding a new project of type “Windows Application Packaging Project” to our solution:

Now we need to specify our min/target versions…

…and let the packaging  project know which project output to include in the package. To do so we right-click on the “Applications” node and set a reference to our Winforms project – done!

Important! Select the “DistributionPackage” project as your startup project. Now hit F5 and watch how your app gets packaged, deployed and launched as a Desktop Bridge app. You can start testing and debugging in this new execution context. If you set the Winforms project as startup project and hit F5, you can still test and debug the unpackaged version of your application

Step 2 – Configure app for Windows Store release

Our app is already running as a Desktop Bridge app now and we have successfully tested and debugged it in this configuration. Next we just need to put some finishing touches on the package so it integrates nicely with the Windows 10 Shell (tiles, badges, etc.) and to make sure it conforms to the Store submission requirements. First thing, we need to replace the default visual assets that come with the project template with our real, application-specific assets. This is very easy now in Visual Studio 2017 with the Visual Assets Manager in the package manifest editor:

To prepare for our Store submission we need to create the application in the Windows Dev Center and reserve our application name, provide screenshots for the store front, set the price, age ratings, etc. If you are not planning to distribute via the Windows Store, you can skip this step.

Last thing we need to do before we can release our app to the public is create a package bundle that is ready to deploy and Store-compliant. This bundle can contain binaries for different architectures, resources for different locales as well as the symbols for our binaries so we can later make sense of any crash reports in the Dev Center or Mobile Center. This can be done for Desktop Bridge apps directly from Visual Studio now, just like you would do for any UWP app:

As part of creating the packages we also run the certification tests and then submit the package to the Dev Center for certification and publishing. You can try the result of my submission out now and install the sample app on your machine from the Store by clicking on the badge below – source code for the app is available for your reference here.

What else does this enable for developers?

Aside from distributing and monetizing via Windows Store, your app now enjoys the modern deployment capabilities built into Windows 10. You don’t need to build an installer anymore, updates are automatic and differential. Uninstalls are guaranteed to be clean. Moreover, since your app is now in the Windows 10 App Model, you have access to UWP APIs and features, such as live tiles, Cortana integration, background tasks etc. Another important benefit specifically for Windows Forms apps is the new high DPI support in .NET 4.7, which is included in the Windows Creators Update (1703). Our sample app here is taking advantage of this new support, by following the steps outlined in this article.

And there is more

Talking about installers, did you know that your app package is also your installer on Windows 10? Users can just click to install it, as long as it’s signed with a certificate that is trusted on the target device. This enables you to distribute your modernized desktop application in the way that’s right for your scenario, without having to go through the Store – e.g. for LOB applications in an enterprise. Learn more about it here.


Getting your desktop application development project ready for Windows Store submission is easy now with Visual Studio 2017 Update 4. Once converted to a Windows App Package your app can take advantage of all the Windows 10 platform capabilities and start using new APIs and features on Windows 10. Here are some resources for more details:

Are you ready to submit your desktop application to the Windows Store? Let us know about it here, and we will help you through the process!

Updated October 19, 2017 8:13 am

Join the conversation

  1. Hi Stefan
    the console application can be also working fine using Windows App Packaging project ?

    Thanks a lot

  2. This is so beautiful, can’t wait to use it!
    You guys are moving in the right direction. Great work.
    Something to think about, what about making UWP as fun to work with like WPF?
    Because now with this great feature, whats the advantage uwp have over wpf?

    • Thanks for your comment – I am glad you like the new project type in VS. To respond to your question: when building a new app for Windows 10, UWP provides a number of great benefits over WPF/Win32 – including the ability to target all Windows 10 devices (PC, Xbox, HoloLens, Surface Hub, etc.), advanced security by running in an appcontainer with capability model, ability to adapt to device form factor, input methods and capabilities, as well as best native experience and integration with new Windows 10 features – such as Fluent design system, modern inking capabilities, MR and many more.

  3. Hi Stefan,

    How can I get user data at during deployment and propagate it to the application config files? Does the APPX packages support user input to be saved into the deployed sandbox environment?


    • Hi Daniel,

      the APPX package deployment does not allow user interaction, it needs to be able to run silently. If user input is required, you should collect it on first run, and store it in the app’s AppData, which is isolated to the app’s environment.


  4. Doesn’t support content files?

    For example if I have a folder in the project and various files tagged as content. In click-once they are included with the install.

    It’s not working for this, so I can publish to the store…

    also (in debug) the Directory.GetCurrentDirectory returns C:\WINDOWS\SysWOW64 this does not seem correct to me.

    • Hi Eric,

      content files are definitely supported. In VS set BuildAction=Content and Copy to Output Directory on your content files and they will get installed with the APPX package.

      In the UWP app model the concept of current directory doesn’t really exist. If you need to access files from the install location, see this blog post: https://blogs.msdn.microsoft.com/appconsult/2017/06/23/accessing-to-the-files-in-the-installation-folder-in-a-desktop-bridge-application/


      • I noticed some files did not have the “Copy Always”, seems click-once doesn’t care.
        currently using AppDomain.CurrentDomain.BaseDirectory, that seems to work

        Also FolderBrowseDialog doesn’t work properly. After creating a new folder, it reports a path that does not exist?

        Private Sub ShowFolderDialog()
        Dim df As New FolderBrowserDialog
        df.RootFolder = Environment.SpecialFolder.LocalApplicationData
        Dim res0 As DialogResult = df.ShowDialog()

        If res0 = DialogResult.Cancel Then
        End If

        Me.tbOutputFolder.Text = df.SelectedPath()
        End Sub

  5. I get this error:
    error APPX0501: Validation error. error 80080204: App manifest validation error: Line 24, Column 6, Reason: Windows.FullTrustApplication entry points are only valid for UWP desktop applications whose minVersion >= 10.0.14257.0.

    My packaging min and target version are the same: 10.0.14393.
    My OS build is 14393.1794

    • Hi Robert,
      this was a bug in the Anniversary Update SDK (14393). If you use a newer version (15063 or 16299) this error will go away. Also you should be able to work around the error with the 14393 SDK by listing both ‘Windows.Universal’ and ‘Windows.Desktop” as TargetDeviceFamily in the appx manifest.


  6. Stephan,
    Great work. At present it appears I cannot package a UWA for Raspberry Pi. VS 2017 does not allow me to choose ARM as the architecture. But I have no problem creating new UWA (no conversion) and deploying that.

    • Hi Ron,
      sorry for the slow reply, been offline for the holidays. At this point in time, packaged desktop applications can only target the Windows 10 desktop SKU. You won’t be able to target IoT devices with such a package.

      Thanks, Stefan