Technologies Documentation Resources

Search
Windows Dev Center Windows apps

Docs / Windows / UWP / Develop Windows apps / Porting apps to Windows10 /

Move from Windows Desktop to UWP / Prepare an app for conversion with the Desktop Bridge

Comments

Edit

Share

Theme Light

Prepare an app for conversion with the Desktop Bridge

Prepare an app for conversion with

the Desktop Bridge
2/8/2017 7 min to read

This article lists things you need to know before converting your app with the
Desktop to UWP Bridge. You may not need to do much to get your app ready for
the conversion process, but if any of the items below applies to your application,
you need to address it before conversion. Remember that the Windows Store
handles licensing and automatic updating for you, so you can remove those
features from your codebase.

Your app uses a version of .NET earlier than 4.6.1. Only .NET 4.6.1 is
supported. You must retarget your app to .NET 4.6.1 before converting.
Is this page helpful?
Your app always runs with elevated security privileges. Your app needs
YES
to NO
work while running as the interactive user. Users who install your app from
 the Windows Store may not be system administrators, so requiring your
app to run elevated means that it won't run correctly for standard users.

Your app requires a kernel-mode driver or a Windows service. The bridge

is suitable for an app, but it does not support a kernel-mode driver or a
Windows service that needs to run under a system account. Instead of a
Windows service, use a background task.

Your app's modules are loaded in-process to processes that are not in
your AppX package. This isn't permitted, which means that in-process
extensions, like shell extensions, aren't supported. But if you have two apps
in the same package, you can do inter-process communication between
them.

Your app calls SetDllDirectory or AddDllDirectory. These functions are not

currently supported for converted apps. We are working on adding support
in a future release. As a workaround, you can copy any .dlls you were
locating using these functions to your package root.

Your app uses a custom Application User Model ID (AUMID). If your

process calls SetCurrentProcessExplicitAppUserModelID to set its own
AUMID, then it may only use the AUMID generated for it by the app model
environment/AppX package. You can't define custom AUMIDs.

Your app modifies the HKEY_LOCAL_MACHINE (HKLM) registry hive. Any

attempt by your app to create an HKLM key, or to open one for
modification, will result in an access-denied failure. Remember that your
app has its own private virtualized view of the registry, so the notion of a
user- and machine-wide registry hive (which is what HKLM is) does not
apply. You will need to find another way of achieving what you were using
HKLM for, like writing to HKEY_CURRENT_USER (HKCU) instead.

Your app uses a ddeexec registry subkey as a means of launching

another app. Instead, use one of the DelegateExecute verb handlers as
configured by the various Activatable* extensions in your app package
manifest. Is this page helpful?

YES NO
 Your app writes to the AppData folder with the intention of sharing data
with another app. After conversion, AppData is redirected to the local app
data store, which is a private store for each UWP app. Use a different means
of inter-process data sharing. For more info, see Store and retrieve settings
and other app data.

Your app writes to the install directory for your app. For example, your
app writes to a log file that you put in the same directory as your exe. This
isn't supported, so you'll need to find another location, like the local app
data store.

Your app installation requires user interaction. Your app installer must be
able to run silently, and it must install all of its prerequisites that aren't on
by default on a clean OS image.

Your app uses the Current Working Directory. At runtime, your converted
app won't get the same Working Directory that you previously specified in
your desktop .LNK shortcut. You need to change your CWD at runtime if
having the correct directory is important for your app to function correctly.

Your app requires UIAccess. If your application specifies UIAccess=true in

the requestedExecutionLevel element of the UAC manifest, conversion to
UWP isn't supported currently. For more info, see UI Automation Security
Overview.

Your app exposes COM objects or GAC assemblies for use by other
processes. In the current release, your app cannot expose COM objects or
GAC assemblies for use by processes originating from executables external
to your AppX package. Processes from within the package can register and
use COM objects and GAC assemblies as normal, but they will not be visible
externally. This means interop scenarios like OLE will not function if invoked
by external processes.

Your app is linking C runtime libraries (CRT) in an unsupported manner.

The Microsoft C/C++ runtime library provides routines for programming for
the Microsoft Windows operating system. These routines automate many
Is this page helpful?

common programming tasks that are not provided by the C and C++ Y E S NO
 languages. If your app utilizes C/C++ runtime library, you need to ensure it
is linked in a supported manner.

Visual Studio 2015 supports both dynamic linking, to let your code use
common DLL files, or static linking, to link the library directly into your code,
to the current version of the CRT. If possible, we recommend your app use
dynamic linking with VS 2015.

Support in previous versions of Visual Studio varies. See the following table
for details:

Visual Studio version Dynamic linking Static linking

2005 (VC 8) Not supported Supported

2008 (VC 9) Not supported Supported

2010 (VC 10) Supported Supported

2012 (VC 11) Supported Not supported

2013 (VC 12) Supported Not supported

2015 (VC 14) Supported Supported

Note: In all cases, you must link to the latest publically available CRT.

Your app installs and loads assemblies from the Windows side-by-side
folder. For example, your app uses C runtime libraries VC8 or VC9 and is
dynamically linking them from Windows side-by-side folder, meaning your
code is using the common DLL files from a shared folder. This is not
supported. You will need to statically link them by linking to the
redistributable library files directly into your code.

Your app uses a dependency in the System32/SysWOW64 folder. To get

these DLLs to work, you must include them in the virtual file system portion
of you AppX package. This ensures that the app behaves as if the DLLs were
Is this page helpful?
installed in the System32/SysWOW64 folder. In the root of the package,
create a folder called VFS. Inside that folder create a SystemX64 and YES NO
 SystemX86 folder. Then, place the 32-bit version of your DLL in the
SystemX86 folder, and place the 64-bit version in the SystemX64 folder.

Your app uses the Dev11 VCLibs framework package. The VCLibs 11
libraries can be directly installed from the Windows Store if they are defined
as a dependency in the AppX package. To do this, make the following
change to your app package manifest: Under the <Dependencies> node,
add:
<PackageDependency Name="Microsoft.VCLibs.110.00.UWPDesktop"
MinVersion="11.0.24217.0" Publisher="CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

During installation from the Windows Store, the appropriate version (x86 or
x64) of the VCLibs 11 framework will get installed prior to the installation of
the app.
The dependencies will not get installed if the app is installed by sideloading.
To install the dependencies manually on your machine, you must download
and install the VC 11.0 framework packages for Desktop Bridge. For more
information on these scenarios, see Using Visual C++ Runtime in Centennial
project.

Your app contains a custom jump list. There are several issues and caveats
to aware of when using jump lists.

Your app's architecture does not match the OS. Jump lists currently
do not function correctly if the app and OS architectures do not
match (e.g., an x86 app running on x64 Windows). At this time, there
is no workaround other than to recompile your app to the matching
architecture.

Your app creates jump list entries and calls

ICustomDestinationList::SetAppID or
SetCurrentProcessExplicitAppUserModelID. Do not
programmatically set your AppID in code. Doing so will cause your
jump list entries to not appear. If your app needs a custom Id, specify
it using the manifest file. Refer to Manually convert your app to UWP
using the Desktop Bridge for instructions. The AppID for your Is this page helpful?

application is specified in the YOUR_PRAID_HERE section. YES NO

 Your app adds a jump list shell link that references an executable in
your package. You cannot directly launch executables in your
package from a jump list (with the exception of the absolute path of
an apps own .exe). Instead, register an app execution alias (which
allows your converted app to start via a keyword as though it were on
the PATH) and set the link target path to the alias instead. For details
on how to use the appExecutionAlias extension, see Desktop Bridge
app extensions. Note that if you require assets of the link in jump list
to match the original .exe, you will need to set assets such as the icon
using SetIconLocation and the display name with PKEY_Title like you
would for other custom entries.

Your app adds a jump list entries that references assets in the app's
package by absolute paths. The installation path of an app may
change when its packages are updated, changing the location of
assets (such as icons, documents, executable, and so on). If jump list
entries reference such assets by absolute paths, then the app should
refresh its jump list periodically (such as on app launch) to ensure
paths resolve correctly. Alternatively, use the UWP
Windows.UI.StartScreen.JumpList APIs instead, which allow you to
reference string and image assets using the package-relative ms-
resource URI scheme (which is also language, DPI, and high contrast
aware).

0 Comments

Sign in 7 people listening

+ Follow Post comment

Is this as...
page helpful?

YES NO
 English

Blog Privacy & Cookies Terms of Use Feedback Trademarks

Is this page helpful?

YES NO