Category Archives: Win32

Auto Added by WPeMatico

Developing for all 1 billion Windows 10 devices and beyond – Windows Developer Blog

This year, Microsoft Build 2020 is a digital-only event that we all get to experience from the comfort of our homes. We hope you enjoy learning about the new features and technologies that matter most to you. Today, I will have the privilege of sharing how developers can build apps for modern work using Microsoft 365 and Windows platforms. I will focus on 4 key areas of improvements to the Windows platform:
Unifying app development across the billion Windows 10 devices for all your current and future apps;
Leaning into the cloud and enabling new scenarios for your Windows apps;
Creating new opportunities for you to build connected apps using Microsoft 365 integration in the Windows experience; and
Making Windows great for developer productivity.

Today we will unveil Project Reunion: our vision for unifying and evolving the Windows developer platform to make it easier to build great apps that work across all the Windows 10 versions and devices people use.
For the past couple of years, we have been breaking down the barrier between Win32 (also called the Windows API) and Universal Windows Platform (UWP) APIs. Project Reunion expands this effort to make it easier to build a great Windows app. It will unify access to existing Win32 and UWP APIs and make them available decoupled from the OS, via tools like NuGet. This will provide a common platform for new apps. Plus, it will help you update and modernize your existing apps with the latest functionality, whether they’re C++, .NET (including WPF, Windows Forms, and UWP) or React Native. As we decouple existing APIs and add new APIs, we are also doing the work to polyfill, as needed, so the APIs work down-level across supported versions of Windows.

One of the first components in the Project Reunion journey is WinUI 3 Preview 1, the high performant, Fluent-optimized native UI framework for Windows. With WinUI developers can build great user experiences that adapt and scale across devices, whether they are starting a new project, or modernizing an existing app.

Image 1: Engaging UI powered by WinUI in Alarms & Clock app
We also know there are times when you want to integrate web content in your native app so you can share code across platforms and with the browser. Today, we are expanding WebView2 (another component in the Project Reunion journey) with a new .NET Preview. Now, any Windows app can embed web content with the power of Microsoft Edge and Chromium. WebView2 provides full web functionality across the spectrum of Windows apps, and it’s decoupled from the OS, so you are no longer locked to a particular version of Windows.

Image 2: Showing an example of a PDF inline using WebView2
We invite you to learn and engage with us at this early stage in the Project Reunion GitHub repo, where we’ll be sharing our progress and listening to your feedback as we implement this vision. You can also learn more about WinUI and WebView2 today.

As organizations shift to enable remote work, Windows Virtual Desktop, built on Azure, has provided the ability to provision and scale virtual desktops and apps faster than was previously possible. It enables organizations to serve your existing app to a growing set of devices that users can access with the Windows Virtual Desktop clients for Windows, MacOS/iOS, and Android.
Because scalability is so important, we introduced a feature called MSIX App Attach. The MSIX App Attach Preview will optimize people’s experiences by untangling the OS image that organizations deploy in the cloud from the apps that people need to access. This means that once you adopt MSIX for Windows desktop, the same investment will soon bring even more benefits when running your app in Windows Virtual Desktop on Azure.

We also know you are looking for more ways to build connect apps, and with Microsoft 365 integrations like Microsoft Search and the Microsoft Graph you have even more opportunities. We all use so many tools and apps and it can be cumbersome to find what we need. But Microsoft Search and the Microsoft Graph can draw unique connections between your people, files, and tools so that you can find what you are looking for. These are just two integrations that allow you and your users to be more efficient, but you can do so much more with the Microsoft 365 platform. Additionally, developers can start using our Graph Connectors that are in preview now, and Microsoft Search will be coming to Windows later this year.

Image 3: Look for a coworker and see pertinent information and shared files and apps

We know it is important for you to stay productive and we appreciate your feedback on how we can make that happen. With advancements to Windows Terminal and Windows Subsystem for Linux you have modern, fast, and powerful tools.
Now available for enterprise use, Windows Terminal 1.0 provides you with the ability to run any command line executable, including WSL distros and Azure Cloud Shell, inside multiple tabs, and panes. You can also use Unicode and UTF-8 characters, have a GPU accelerated text rendering engine, and custom themes, styles, and configurations. The Windows Terminal is available on the Microsoft Store or manually from the Terminal GitHub repo.
Improvements to Windows Subsystem for Linux (WSL) have centered around enabling hardware acceleration, running a Linux GUI app directly, and making it easier to start using Linux apps on Windows. Here are a few details:
Added support for graphics processing unit (GPU) compute workflows allows Linux tools to leverage GPUs to enable hardware acceleration for many development scenarios, such as parallel computation and training machine learning (ML) and artificial intelligence (AI) models.
Support for Linux graphical user interface (GUI) apps will enable you to open a WSL instance and run a Linux GUI app directly without the need for a third-party X server. This will help you to run your favorite apps in a Linux environment such as an integrated development environment (IDE).
WSL will soon support a simplified install experience by running the command ‘wsl.exe – install,’ which will make it easier than ever to start using Linux apps on Windows.
Additionally, preview tools and utilities, like the Windows Package Manager and Microsoft PowerToys, provide you with paths to streamline your Windows experience for even greater development productivity.
You asked for an easier way to setup your development environment and now with the Windows Package Manager Preview you have a command line interface enabling you to install your favorite tools quickly and easily. The repository of packages is open source, and we can’t wait for you to contribute and help us with the next level of improvements.
With Microsoft PowerToys (0.18) you can customize the Windows 10 shell for your personal workflows. Today’s updates add two new utilities: Keyboard Remapper and PowerToys Run. You can remap key to key and shortcut to shortcut using Keyboard Remapper. And, PowerToys Run, an app launcher utility gets you to your programs faster than before – hit alt-space and just start typing.
We look forward to working with you in the open to make progress on each of these efforts, so we can help you build productive and delightful experiences. I can’t wait to see what we can build together with WinUI, WebView2, Terminal, Windows Package Manager Preview, Project Reunion and more. If you didn’t get enough at Build, you can find additional deep-dive content on topics like WSL, Terminal, React Native for Windows, WebView2, Windows AI, and much more at Microsoft365.

Microsoft Emulator and Windows 10X Emulator Image (Preview) build 19578 available now! – Windows Developer Blog

Today we released new versions of both the Microsoft Emulator and the Windows 10X Emulator Image (Preview) to the Microsoft Store. The updated Microsoft Emulator is version and the updated Windows 10X Emulator Image is version 10.0.19578. This refresh includes many updates to Windows 10X including the Win32 Container. Information on installation and requirements can be found at Get Windows dev tools.
We want your feedback so please use the Feedback Hub!

Check for new images in the Emulator!
The Microsoft Emulator version now includes the ability to query the Store for updated images and install them. On first run of the emulator, if there are no images installed, it will prompt to download an image. The developer can also choose to check for new images through the File->’Download emulator images’ menu item.

Test existing applications in the emulator on released versions of Windows
The Windows 10X Emulator Image version 10.0.19578 includes a new EULA that no longer requires it to be installed on a Windows Insiders machine. You can now install it on Windows 10 version 10.0.17763 or higher. With released SDKs, developers can use this new configuration to test their existing apps on the dual-screen devices and to enhance their app experiences with dual-screen patterns; taking advantage of TwoPaneView class and leveraging the Wonder Bar with CompactOverlay.
Reminder, in order to use the Insiders Preview SDK, developers must setup their environment on a Windows Insiders OS
Win32 apps now participate in the windowing model
This update applies the windowing model for Windows 10X to your Win32 apps running in the container. System-defined window placement ensures that users have a consistent and simplified windowing experience that is tailored and appropriate to a smaller, dual-screen, and touch-friendly device. Some gaps remain and will be addressed in future updates.
Additional details can be found in the RelNotes for the release.

Identity, Registration and Activation of Non-packaged Win32 Apps – Windows Developer Blog

Many new and sought-after Windows APIs and features such as BackgroundTasks, Notifications, LiveTiles, Share and more, are either not available or not easily callable from non-packaged Win32 applications. This is due to the programming model for UWP APIs that integrate with the system and have a dependency on the following concepts:Identity – The need for package or application identity to identify the caller, and an identifier to scope data and resources.
Registration – The need for configuration of machine state during application deployment, which is required by the API and indexed by the package or application identity.
For packaged applications, Identity declared in the Appxmanifest.xml, and Registration is handled by the MSIX deployment pipeline based on the information in the AppxManifest.xml. This allows a simplified calling pattern for UWP APIs where the application code just uses an API. Compare this to a typical Win32 API that requires a register-use-unregister pattern for managing a callback.
We’ve heard your feedback, and in response we’re filling in the divide between Win32 apps and new Windows APIs & features so that you can take advantage of these new APIs & features and enhance your applications. As of Windows Build 10.0.19000.0 we’re introducing the following new AppModel concepts to provide your Win32 app with deeper integration into the OS:
Sparse Package registrationSigned MSIX packages can be installed on Windows today but all content referenced in the package’s Appxmanifest.xml must be present inside the package. A ‘Sparse’ Package contains an AppxManifest.xml but unlike a regular/full package, the manifest can reference files outside its package in a predetermined ‘external location’. This allows applications that are not yet able to adopt complete MSIX packaging to gain Identity, configure state (Registration) as required by UWP APIs and then take advantage of these APIs.
Package ‘External Location’ To support a Sparse Package, a package definition now has a new element. This is what allows your package AppxManifest.xml to reference content outside its package, in a specific location on disk. For example, if your existing Win32 app installs content in C:Program FilesMyWin32App , you can create a Sparse Package that declares the element and during app installation or first run of your app, you can register the Sparse Package and declare C:Program FilesMyWin32App as the external location your app will be using. This way you can continue deploying all your other app artifacts in the locations you do today while taking advantage of the Sparse Package.
Win32 type RuntimeBehaviorTo help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.
Activation via CreateProcessThe activation path for UWP applications today ensures the app has PackageIdentity in its process token. This is used by UWP APIs to identify the caller and refer to later – either to perform a callback or to look up state that was configured during deployment. Because of this requirement, calling CreateProcess() on a UWP exe will fail as the CreateProcess() pipeline was not enlightened about Identity. In order to support Sparse Packages with an External Location, we leverage the classic Win32 application.manifest to provide Identity in CreateProcess() scenarios.
At their core, these features are about providing a foundation for non-packaged Win32 processes to use our latest APIs and features.
*Please note that these are still new and somewhat advanced development features that do not yet have full Visual Studio integration i.e. there are still some gaps in the end to end authoring experience such as having to create a Sparse Package outside of Visual Studio.

We’ll be using a sample application making use of a Sparse Package to walk through the different aspects of Sparse Package authoring and usage. The demo app is located at
We have a non-packaged WPF application PhotoStoreDemo that stores and displays photos. In its purely non-packaged state, it can be challenging to take advantage of new Windows APIs and features. Our goal is to change this by creating a Sparse Package and continuing to use our previously existing Win32 app artifacts.
Anatomy of a Sparse Package
A Sparse Package must have an AppxManifest.xml and a minimal set of required visual assets in order to deploy.


Let’s use the AppxManifest.xml from our sample code above to look at the anatomy of a Sparse Package.
Package External Location
Firstly, the AppxManifest should declare the package property. This allows the manifest to reference content that is not located within the package. Any content referenced in the Sparse Package that isn’t located in the package directly should be in the ‘external’ location which is specified when the Sparse Package is registered. For example, if I declare my package’s external location to be C:Program FilesMyDesktopApp during installation or at first run, the image storelogo.png defined for the property should be installed at C:Program FilesMyDesktopAppAssetsstorelogo.png and the main application executable PhotoStoreDemo.exe should be installed at C:Program FilesMyDesktopAppPhotoStoreDemo.exe. In addition, the MinVersion should be OS Build 10.0.19000.0 or greater, Sparse packages are currently not supported on OS versions earlier than this.
It’s important to note that unlike a fully packaged application, an app using a Sparse Package + ‘External Location’ is not fully managed by the OS at deployment, runtime and uninstall. As is the case with Win32 apps today, your application is responsible for install and uninstall of all its artifacts including the Sparse Package and any content in the ‘external location’. This also means your app doesn’t receive lifetime management and tamper protection that fully packaged apps receive from being installed in a locked down location on the System.
Win32 Runtime Behavior
The newly introduced TrustLevel=mediumIL and RuntimeBehavior=Win32App attributes in the element are used to declare that the application associated with this Sparse Package will run like a Win32 app, with no registry + filesystem virtualisation and other runtime changes.
Sparse Package Authoring
The steps required in authoring Sparse Package are:
Create an AppxManifest.xml + Visual Assets and package them
Sign the Sparse Package
Create a classic Win32 application.manifest in your Win32 app
Register the Sparse Package
Creating and Packaging an AppxManifest.xml + Visual Assets
The first step in creating a Sparse Package is generating the AppxManifest.xml. The AppxManifest needs to contain the properties listed above, you can use this template as a starting point. In addition to the AppxManifest you need to include the visual assets referenced in the manifest file. You can use the “Visual Assets” node in the package.manifest editor of the Visual Studio Application Packaging Project to generate the visual assets.
Once you have your AppxManifest.xml and visual assets, you can use App Packager (MakeAppx.exe) to create a Sparse Package. Because the Sparse package doesn’t contain all the files referenced in the AppxManifest.xml, you need to specify the /nv command.
Here is an example command to create a Sparse Package containing just an AppxManifest.xml from a VS Developer Command Prompt:
MakeAppx.exe  pack  /d    /p  mypackage.msix  /nv
You can find more info on App packager (MakeAppx.exe) here.
Signing a Sparse package
To successfully install on a machine, your Sparse Package must be signed with a cert that is trusted on that machine. This is the case for regular MSIX packages today. You can create a new self-signed cert for development purposes and sign your Sparse Package using the SignTool available in the Windows SDK and MSIX Toolkit. You can also make use of the newly announced Device Guard Signing feature.Here’s an example of how to sign a Sparse Package from a VS Developer Command Prompt using the Sign Tool:
SignTool.exe sign /fd SHA256 /a /f mycert.pfx  /p   mypackage.msix
Creating a classic Win32 application.manifest
To support CreateProcess() scenarios that do not go through the UWP activation pipeline, your app must use the classic Win32-style application.manifest to declare the identity attributes of your application under the new element. The values defined in the manifest are used determine your application’s identity when its executable is launched and must match those declared in your Sparse Package’s AppxManifest.xml.

packageName (above) corresponds to Name and publisher corresponds to Publisher in the element of your Sparse package:
(Sparse Package)

applicationId corresponds to the Id attribute in the element for this app declared in the Sparse package:
(Sparse Package)


To add a classic Win32 manifest to an existing project in Visual studio, from the application node right click | Add | New Item | Visual C# | Application Manifest File. The manifest file naming convention is that it must have the same name as your application’s .exe and have the .manifest extension, in this case I named it “PhotoStoreDemo.exe.manifest”.
Taking advantage of your app’s Sparse Package
As earlier mentioned, creating a Sparse Package for your application makes it easier for your Win32 app to deeply integrate with the OS and take advantage of features such as BackgroundTasks, Share, Notifications and Tiles. Let’s have a look at how our sample app runs and uses the Sparse Package to register as a Share Target and make use of UWP activation.
The workflow in our sample looks something like this:
Declare our app as a Share Target in the Sparse Package AppxManifest.xml
Register our app’s Sparse Package with the OS.
Relaunch the app and handle activation types.
Example usage – Declaring your app as a Share Target in the Sparse Package AppxManifest.xml
Our sample app is registered as a Share Target by declaring the windows.ShareTarget Application Extension in the Sparse Package AppxManifest.xml:



Registering a Sparse Package
To take advantage of a Sparse package, your application needs to register the signed package with the system. You can register the package during first run, or you can also register the package during installation of your other Win32 artifacts, if you’re using an installer such as an MSI. To install the package using an MSI you’d need to use Custom Actions. In our sample app, we register the Sparse package during first run. When our application is launched, we check if it’s running with Identity (identity or the lack thereof is a signal of whether the Sparse package has been registered/installed) if the app is not running with identity we then register the Sparse Package and restart the app. This is expected to take place only once at first run. To see how we’re determining if the app is running with identity, have a look at the ExecutionMode class and this post if you’d like more background.
This is what the code in our app looks like:

//if app isn’t running with identity, register its sparse package
if (!ExecutionMode.IsRunningWithIdentity())
string externalLocation = @”C:\”;
string sparsePkgPath = @”C:\PhotoStoreDemo.msix”;

//Attempt registration
if (registerSparsePackage(externalLocation, sparsePkgPath))
//Registration succeded, restart the app to run with identity
System.Diagnostics.Process.Start(Application.ResourceAssembly.Location, arguments: cmdArgs?.ToString());
else //Registration failed, run without identity
Debug.WriteLine(“Package Registation failed, running WITHOUT Identity”);
SingleInstanceManager wrapper = new SingleInstanceManager();


And this is the registerSparsePackage method called above handling package registration:

Using Windows.Management.Deployment

private static bool registerSparsePackage(string externalLocation, string sparsePkgPath)
bool registration = false;
Uri externalUri = new Uri(externalLocation);
Uri packageUri = new Uri(sparsePkgPath);
PackageManager packageManager = new PackageManager();
//Set the externalLocation where your Win32 artifacts will be installed
//Anything not in the package but referenced by your AppxManifest.xml needs to to be under this location
var options = new AddPackageOptions();
options.ExternalLocationUri = externalUri;

Windows.Foundation.IAsyncOperationWithProgress deploymentOperation = packageManager.AddPackageByUriAsync(packageUri, options)

To register the Sparse packages, you need to make use of the PackageManager AddPackageByUriAsync(packageUri, addPackageOptions) API. The API takes in the location of your signed Sparse Package as a URI and an AddPackageOptions object. You need to create an AddpackageOptions object and set the ExternalLocationUri property to the URI of the location where your Win32 artifacts (e.g. app executable) being referenced in the Sparse Package will be installed.
Handling App Activation
When our app is running, we check whether it was launched under UWP type activation e.g. a Share Event or Notification Event. If it was, we handle the activation event accordingly, otherwise, we handle the launch as a regular .exe launch such as double clicking the app .exe. Here’s a look at the code:

public static void Main(string[] cmdArgs)

//Handle Sparse Package based activation e.g Share target activation or clicking on a Tile
// Launching the .exe directly will have activationArgs == null
var activationArgs = AppInstance.GetActivatedEventArgs();
if (activationArgs != null)
switch (activationArgs.Kind)
case ActivationKind.Launch:
HandleLaunch(activationArgs as LaunchActivatedEventArgs);
case ActivationKind.ToastNotification:
HandleToastNotification(activationArgs as ToastNotificationActivatedEventArgs);
case ActivationKind.ShareTarget:
HandleShareAsync(activationArgs as ShareTargetActivatedEventArgs);

//This is a direct exe based launch e.g. double click.exe or desktop shortcut
SingleInstanceManager singleInstanceManager = new SingleInstanceManager();

Running the Sample
To run the sample app at
Make sure your machine has Developer Mode turned on, and both your Windows Build and SDK versions are 10.0.19000.0 or later.
Retarget the solution to the SDK version on your machine – Right click -> Retarget solution.
Add a project reference to the Windows.winmd file at “C:Program Files (x86)Windows Kits10UnionMetadata\Windows.winmd”(Right click PhotoStoreDemo project | Add | Reference| Browse | All files | Windows.winmd)
Make sure the Sparse Package is signed by a trusted cert on your machine.
You can sign using an existing cert or you can create a self-signed cert and trust it on your machine by double clicking | Install certificate | Local Machine | Place all certificates in the following store | Browse | Trusted People | Next | Finish
Update, package and sign the unpackaged files in PhotoStoreDemoPkg. Open the AppxManifest.xml and update the Publisher value in the package element to match the publisher value in your cert. *You will also need to make sure the Publisher value is updated in the classic Win32 app.manifest (PhotoStoreDemo.exe.manifest) to match the new value in the AppxManifest.xml.
Follow the steps under “Creating and Packaging an AppxManifest.xml” and “Signing a Sparse Package” sections to package the files with App Packager (MakeAppx) and then sign them with the SignTool or Device Guard Signing.

Once the Sparse Package is signed, in the main method (in Startup.cs) update the externalLocation value to match the output location of your VS Build binaries and the sparsePkgPath value to match the path to your signed Sparse Package.
When you run the package, you should see the PhotoStoreDemo app launch with a “Running with Identity” tag in the top left corner. If registration of the package failed the tag will read “Desktop App” instead. If the package registration was successful and the app still launches without identity, try double checking to make sure the values in the element of the classic Win32 app.manifest (PhotoStoreDemo.exe.manifest) match the values in the and element of your Sparse Package’s AppxManifest.xml.
Launching the app with identity:

Checking the Details tab in Task Manager shows the app running with a Package Name PhotoStoreDemo which is an indicator that the app is running with our Sparse Package’s declared identity:

After my app has successfully registered the Sparse package, it shows up as a Share target when I right click on a .jpg/.png/.gif file:

Selecting our app activates the app and adds the new image to the image store.

As a bonus, our sample handles toast notification activation in the HandleToastNotification() method in Startup.cs. Clicking the “Add Via Toast” button in the bottom left quadrant of the running app launches a toast message from the app.

If you enter a full path to an image file, it should add the image file to the app’s photo store. If you close the app before responding to the toast, it will relaunch the app with the new image you specified in the path.

Unlike a fully packaged application that is uninstalled by the System when a user chooses to uninstall the app, a Sparse Package must be uninstalled by the application that registers it. The uninstall workflow of a Sparse Package points the user to the uninstaller of the application that registered the package and while uninstalling the Win32 artifacts of the app, the uninstaller must also remove the Sparse Package. This can be done using the PackageManager.RemovePackage..() APIs, you can find an example of an app using the APIs here.
Adding a Sparse Package to your existing Win32 app is a great way to give your application identity and add deeper integration with Windows APIs and features such as Notifications, BackgroundTasks, Live Tiles, Share and more. The main caveats are that unlike for fully packaged applications, your application does not receive tamper protection and installation in a locked down location. In addition, your app is not fully managed by the OS at deployment, runtime and uninstall – your application is responsible for install, lifetime management and uninstall of your Sparse Package, in the same way you are responsible for installing and managing your Win32 app artifacts.

Early preview of Visual Studio support for Windows 10 on ARM development

Today, we are pleased to announce that Visual Studio 15.8 Preview 1 contains an early preview of the SDK and tools to allow you to create your own 64-bit ARM (ARM64) apps. These tools answer the requests of many eager developers, and the development made possible with these tools represents the next step in the evolution of the Always Connected PC running Windows 10 on ARM.
Earlier this year, our partners released the first Always Connected PCs powered by Qualcomm Snapdragon 835 processors. These Always Connected PCs are thin, light, fast, and designed with instant-on 4G LTE connectivity and unprecedented battery life – now measured in days and weeks, not hours. Thanks to an x86 emulation layer, these Always Connected PCs also allow customers to tap into the wide ecosystem and legacy of Windows apps.
Developers interested in targeting this new ARM-based platform can use these early preview tools to build apps that run natively on ARM processors rather than relying on the emulation layer. While the algorithms that make emulation possible are engineered to optimize performance, running your app natively allows your customers to get the most performance and capability from your app on this new category of devices.
Since this is an early preview, there isn’t official support yet for the ARM64 apps built with these tools. You won’t be able to submit ARM64 packages to the Microsoft Store, though you can post preview versions of ARM64 Win32 apps to your website. Stay tuned to this blog for more information as more support becomes available. In the meantime, you can use these preview tools to get a head start on developing your ARM64 apps and provide feedback before the tools are finalized.
In this post we’ll look at how to set up your environment to build ARM64 apps, whether you’re building Universal Windows Platform (UWP) apps or C++ Win32 apps.
C++ UWP App Instructions
To build ARM64 UWP apps based on C++, start by setting up your development environment:
1) Download Visual Studio’s latest preview at Choose the “Universal Windows Platform development” workload3) Select the “C++ Universal Windows Platform tools” optional component4) In Individual Components, select “C++ Universal Windows Platform tools for ARM64”
The Visual Studio Installer should look like this when everything that is required is selected:

After installing, you can get started on your app:
5) Open your C++ Project in Visual Studio, or create a new one6) Right click on your Solution and select Properties, then navigate to Configuration Properties and select “Configuration Manager”7) Under “Active solution platform:” select “” and call it ARM64. Copy settings from “ARM” and check to create new project platforms8) If individual projects within the solution do not allow adding ARM64 as a platform, it may be because of dependencies. To learn more about the dependencies, you can modify those project files directly, copying the ARM configuration and modifying the platform to create an ARM64 configuration.9) Save everything
ARM64 will now be available as a configuration for the project to build. Note that only Debug builds are supported for ARM64 at this time. You can create a package for sideloading or use remote debugging (see instructions) to run the app on a Windows 10 on ARM PC.
.NET Native UWP App Instructions
To build ARM64 UWP apps that rely on .NET Native, start by setting up your development environment.
1) Download Visual Studio’s latest preview at Choose the “Universal Windows Platform development” workload3) Open your project or create a new one. Note that the Target Platform Minimum Version must be set to at least “Windows 10 Fall Creators Update (Build 16299)”4) Open the project file in your favorite editor and add a property group targeting ARM64. You can copy an existing property group, such as Debug|ARM, and modify it to support ARM64 with the changes highlighted below:

The UseDotNetNativeToolchain property is required to enable the .NET Native toolchain.
5) Save the project file and reload it in Visual Studio6) Right click on your Solution and select Properties, then navigate to Configuration Properties and select “Configuration Manager”7) Under “Active solution platform:” select “” and call it ARM64. Copy settings from “ARM” and check to create new project platforms8) Update to latest ARM64 version of the tools:
a. Right-click your project and select ‘Manage NuGet Packages…’b. Ensure “Include Prerelease” is selectedc. Select the Microsoft.NETCore.UniversalWindowsPlatform packaged. Update to the following version: 6.2.0-Preview1-26502-02
ARM64 will now be available as a configuration for the project to build. Note that only Debug builds of ARM64 are supported at this time. You can create a package for sideloading or use remote debugging (see instructions) to run the app on a Windows 10 on ARM PC.
C++ Win32 App Instructions
Visual Studio 15.8 Preview 1 also includes an early level of support for rebuilding your C++ Win32 apps as ARM64 to run on Windows 10 on ARM.
1) Download Visual Studio’s latest preview at Choose the “Desktop development with C++” workload3) In Individual Components, select “Visual C++ compilers and libraries for ARM64”4) Open your project in Visual Studio or create a new one5) Right click on your Solution and select Properties, then navigate to Configuration Properties and select “Configuration Manager”6) Under “Active solution platform:” select “” and call it ARM64. Copy settings from “ARM” and check to create new project platforms.7) Save everything8) Open the project file in your favorite editor. Under , declare support for ARM64 by adding WindowsSDKDesktopARM64Support, as highlighted below:

9) Save and reload the project
You will now be able to build the project as ARM64 and either remote debug on a Windows 10 on ARM PC or copy over the EXE files and run them directly.
You can also use the Desktop Bridge (see instructions) to wrap the built ARM64 binaries into a Windows app package that can be installed on Windows 10 on ARM PCs.
We’re excited to open up Windows 10 on ARM to developers looking to build great apps compiled natively for the platform.
Visual Studio 15.8 Preview 1 provides an early preview of the full support that will be coming later this year. You can expect more updates as we work to bring these tools to an official release and open the Store to accept submissions for ARM64 packages.
We hope you give these tools a try on your apps and would love to hear from you. If you hit any issues, have any questions, or have feedback to share, head to our Windows 10 on ARM development page at or leave comments below.

Extend your desktop application with Windows 10 features using the new Visual Studio Application Packaging Project

Visual Studio 2017 15.4 introduced the new Windows Application Packaging project to help you modernizing your application by using the new Windows 10 App Deployment Stack.
We talked about it in our previous post: Visual Studio 2017 Update 4 makes it easy to modernize your app and make it store ready and today we want to describe the new capabilities in Visual Studio 2017 15.5 that enable new scenarios to the Windows application packaging project to take advantage of more Windows 10 features in your applications.
During this article we will cover three examples to highlight the new capabilities added to the packaging project to enable packaging for not only Win32 applications, but also UWP applications and components:
Background execution using UWP background tasks.
Windows Shell integration using the Share Target contract.
Include Win32 code investments in your UWP app package.
The first two samples are existing WPF applications packaged as APPX with extended functionality implemented as UWP components. The first application adds background execution based on UWP background tasks, while the second app shows how to deeply integrate the application with the Windows 10 shell using a widely available feature as Share contracts. Finally, the last app is a UWP entry point that calls to a classic Win32 process that interop with Excel.
Note: Because the UWP components require to be compiled for a specific platform: x86 or x64, the Any CPU solution configuration will not work in any of these samples.
All samples are available in the GitHub repo Windows-Packaging-Samples. These samples require Visual Studio 2017 15.5 Preview 4 or greater, available to download from
1. WPF with Background Tasks
The Universal Windows Platform includes support for advanced background processing. Background tasks allow running code even when the app is suspended. Background tasks are intended for small work items that do not require user interaction, such as downloading mail, showing a toast notification for an incoming chat message or reacting to a change in a system condition.
To show how to use this feature from your Win32 applications, we are going to implement a small utility that will make an HTTP request to a URL configured by the user and will show the elapsed milliseconds in a Toast Notification.

We will create a WPF application to allow the user to specify the URL to check and enable/disable the background task. The background task will be implemented as a Windows Runtime Component (WINMD). To be able to include this component in the package, we need to create a UWP application that uses the component, and finally add the WPF and UWP projects as references to the packaging project. Below is the list of steps needed.
You can find the complete source code of this sample in the GitHub repository, but if you want to create the sample from scratch here are the most important steps.
Package your desktop application using the packaging project
Add a Windows Runtime component to implement the background task
Add a UWP application that reference the runtime component
Add a reference to the UWP application from the packaging project
Configure the Background task in the manifest
Register the background task from the Desktop application
Once you completed steps 1 to 4, you should have a solution for projects as shown in the image below:

The packaging project references not only the WPF application, but also the UWP project. For this reason, the solution needs to be configured for a specific platform, since UWP is not available for Any CPU configurations.
Background Task implementation
The background task is a C# class that implements the IBackgroundTask interface. This interface defines the Run method that will be called when the system triggers the task.

public sealed class SiteVerifier : IBackgroundTask
public async void Run(IBackgroundTaskInstance taskInstance)

taskInstance.Canceled += TaskInstance_Canceled;
BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
var msg = await MeasureRequestTime();

private async Task<string> MeasureRequestTime()
string msg;
var url = ApplicationData.Current.LocalSettings.Values["UrlToVerify"] as string;
var http = new HttpClient();
Stopwatch clock = Stopwatch.StartNew();
var response = await http.GetAsync(new Uri(url));
var elapsed = clock.ElapsedMilliseconds;
msg = $"{url} took {elapsed.ToString()} ms";
catch (Exception ex)
msg = ex.Message;
return msg;

Note how we use the LocalSettings in ApplicationData to share information between the WPF application and the UWP background task.
To configure the background task, you need to update the manifest using the manifest designer. Go to the declarations tab, add the background task and configure the entry point as the implementation.

To register the background task in the system, we need to call a Windows 10 API from the WPF application. This API is available in the Windows 10 SDK, and to use it from .NET we need to add the references explained here. Once you have access to the Windows 10 API you can use  the BackgroundTaskRegistration class to configure the background task as shown in the code below:

public void RegisterBackgroundTask(String triggerName)
var current = BackgroundTaskRegistration.AllTasks
.Where(b => b.Value.Name == triggerName).FirstOrDefault().Value;

if (current is null)
BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
builder.Name = triggerName;
builder.SetTrigger(new MaintenanceTrigger(15, false));
builder.TaskEntryPoint = "HttpPing.SiteVerifier";
System.Diagnostics.Debug.WriteLine("BGTask registered:" + triggerName);
System.Diagnostics.Debug.WriteLine("Task already:" + triggerName);

To register the background task, first we make sure the task has not been registered before, and then we use the BackgroundTaskBuilder to configure the name and the Trigger, in this case we are using the MainteinanceTrigger.
2. Register your application as Share Target
Share contracts is a Windows 10 feature that allows the sharing of information between two apps, the sender and the receiver. Thanks to the Desktop Bridge, we can register a UWP application as a Share receiver and then integrate with a Win32 application. Once the app is registered, it will be shown every time the user invokes a share operation as shown below:

In this sample, we are extending a WPF application to become a share target where users can send images from other apps like the Photos app, Edge or even the Shell to our application. We are using the packaging project to include not only the WPF application, but also a UWP application that allows a UWP UI to receive events from the share target. Below you can see the solution explorer with the packaging project referencing the WPF and UWP projects.

The package needs to declare the Share Target, including the name of the UWP application:

When the application gets activated, it receives the share target information from the ShareOperation parameter as shown in the code snippet below:

protected async override void OnNavigatedTo(NavigationEventArgs e)
operation = (ShareOperation)e.Parameter;
if (operation.Data.Contains(StandardDataFormats.StorageItems))
var items = await operation.Data.GetStorageItemsAsync();
file = items[0] as StorageFile;
IRandomAccessStreamWithContentType stream = await file.OpenReadAsync();

await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
BitmapImage image = new BitmapImage();
this.img.Source = image;
await image.SetSourceAsync(stream);

Now every time the user shares a picture and selects our application, the Share UI application gets invoked and the UWP UI will be displayed.

After clicking the “Share to WPF app” button, the UWP will process the event handler, and will copy the picture to the ApplicationData folder and run the Win32 application using the FullTrustProcessLauncher.

private async void ShareBtn_Click(object sender, RoutedEventArgs e)
await file.CopyAsync(ApplicationData.Current.LocalFolder);
await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();

To use the FullTrustProcessLauncher we will use the Desktop extension to UWP, this extension is available as an SDK reference available in the Add References dialog of the UWP application:

And finally, register the desktop extension and the target executable in the manifest:

<Package xmlns=""
IgnorableNamespaces="uap mp rescap desktop">
<… >
<desktop:Extension Category="windows.fullTrustProcess"
Executable="WPFPhotoViewerWPFPhotoViewer.exe" />
<… >

3. Enable Office interop from UWP application
One of the key features of the Desktop Bridge is the ability to include Win32 executables on your application package and run those as full trust process from a UWP application. Now, with the Windows Application Packaging project, you can create packages that contain both UWP and Win32 binaries.
Additionally, to the process launcher, the App Service extension will help you to establish a communication channel between your UWP application and the Win32 process.
In this sample we are going to include a Win32 process (a command line application) to manage an Excel worksheet using office interop.
We start with a UWP application that uses the Telerik data grid to show some tabular data, and we will add button to export the same data to Excel as shown in the image below:

The solution explorer of this example looks very similar to our previous example, with three projects in the solution: The UWP application, the Win32 command line and the packaging project with a reference to both projects. However, note that in this case the Application entry point (shown in bold) is the UWP project:

As we did in our previous example, we need to add a reference to the Desktop extension and register the full trust process in the manifest. But this time, we will also register the application service in the package manifest:

To open the communication channel in the Win32 process, we will add a reference to the Windows API as described here:
To establish the connection, we will use the AppServiceConnection class, where we need to specify the package family name of the application we want to connect with, and the event handlers we will use to process the incoming requests.

Connection = new AppServiceConnection();
connection.AppServiceName = "ExcelInteropService";
connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;
connection.RequestReceived += Connection_RequestReceived;
connection.ServiceClosed += Connection_ServiceClosed;

The new features added to the packaging project in Visual Studio 2017 will help you to modernize your existing desktop applications to get the best from UWP and Win32 in the same package. This new project will help you to configure your package by using the manifest designer, debug your application in the context of the Desktop Bridge and finally, help to create the packages for store submission or sideloading. Here are some resources for more details:
Desktop Bridge docs
Desktop Bridge samples
Windows Application Packaging project samples
App Modernization video on Channel 9
Are you ready to submit your desktop application to the Microsoft Store? Let us know about it here, and we will help you through the process!