This guest blog post is by Tim Mangan, owner of TMurgent Technologies, LLP. Awarded a Microsoft MVP for Application Virtualization, and CTP by Citrix, Tim speaks and writes about all forms of virtualization as well as performance topics around the world.
With the Anniversary Update to Windows 10 this summer, Microsoft made the official release of the Microsoft Desktop Bridge for Windows, formerly known as Project Centennial. The Desktop Bridge is a transitional approach that Microsoft is using to encourage software vendors to start the process of migrating older software technologies, such as traditional "Win32", ".Net", and "Java" apps towards Universal Windows Platform (UWP) Apps.
The Desktop Bridge is (currently) the only way to get these applications into the Microsoft Store, or Microsoft Store for Business without a complete rewrite, in many cases, especially for software that is targeted at businesses rather than consumers, the traditional applications.
In essence, a Desktop Bridge is a hybrid package. It uses the AppX packaging format, with an extension. The AppX format is what is used in UWP Apps, and the extension allows certain "full trust" software to be included. Package management, shortcuts, and file associations are identical to UWP, but the software is not bound by the severe limitations of .NET Core. That isn't to say that there aren't restrictions in what your "traditional" code can do, but we'll get to that later.
In September, Microsoft finally worked out the initial rules and procedures to allow Desktop Bridge and at the Build conference they announced that the first products using Microsoft Bridge are in the Microsoft Store. We can't really tell which ones are Bridge apps as they are not designated in any way until you download and try to install them. At that point the user will see a barely noticeable designation that this is a "full trust" app. As we will see, the use of the designation "full trust" in this case is only in relation to UWP apps; I would claim that these apps are "more trusted than UWP", but certainly not fully trusted!
Desktop App Converter
In October, Microsoft also released the Desktop App Converter, a UWP front end to their Windows Container based install-capture style converter. It requires a Windows 10 1607 OS.
|While an install-capture technique may seem unusual to
developers, it is a well-known technique that IT Pros at your
customer routinely use to repackage
This technique will cause execution of all the dependencies and installer custom actions one time on a reference machine and then capture the (hopefully) relevant changes. Typically, the dependent environment must be clear of the dependencies, and therefore is usually performed on a clean OS.
Install-capture typically uses some form of filtering to remove unwanted noise such as temporary files, and in some cases unwanted noise due to normal windows software running in the background. But the technique can capture extra noise, so some manual cleanup is typically advised.
It is necessary to execute the dependent installers and custom actions as part of creating the desktop bridge package, as actions taken by the custom actions will typically not be allowed to run at the end-user's machine.
In addition to installing the UWP App, you must enable the Windows Containers feature of the operating system, and download and prepare a WIM file for use of the same OS version that you are running. You supply a set of files and a command to run that will silently install the software. The install must be silent because no user interaction is possible because the install will occur inside a container that provides no user interface. The converter app will spin up a container, map the files into the container, and cause the install to run while redirecting file and registry changes to a special area for processing, and then produce the AppX package. I have found that with a bit of spelunking you can locate and modify some of the PowerShell based scripting and alter the exclusions used, but very little control over the process is available. In the end, you'll get an initial version of the package, but it is in no shape to upload to the store. For example, all icons, including those on the start menu, would be a gray X. But you do have an AppX package that you can test to see what works or not.
By contrast, if you use Advanced Installer Architect edition, that includes its own Desktop App Converter feature. This feature will also perform an install-capture operation to generate the APPX package, either on the installed OS (not recommended), or on a pre-configured virtual machine. Using the Advanced Installer converter, you have more control over the filtering, icons are generated automatically, and an AIP project is generated so that you can easily edit the package and continue to rebuild as needed.
If your application has dependencies, hopefully your existing installer that you will run in this converter will automatically take care of them. If not, it may be necessary to start the Advanced Installer Desktop App Converter with a script that installs the dependencies and then launches your installer. While I still recommend working out a complete silent installation script before attempting the conversion, this converter does have a nice feature that will try to automate default actions by clicking default dialog box buttons for you.
The biggest problem that I had with this tool was with the automatic icon generation that it attempts. The Microsoft store doesn't allow transparency in the Store Icons, so the Advanced Installer Converter translated my icons for me, adding a blue background. Unfortunately, my Icon was transparent and blue; although a different shade of blue it made for a poor user experience! But a swap out of the icon in the Advanced Installer project afterwards quickly solved the issue. Still, this attempt is better than the gray box with a X in it that the Microsoft tool produces!
Desktop Bridge Apps Limitations
Desktop Bridge Apps cannot do everything that traditional apps do, and there is no master list of what the capabilities or limitations are. In some cases, these limitations may be temporary, as Microsoft continues to improve coverage. But many are architectural or founded in the fundamental principle of "do no harm" – Desktop Bridge Apps may not make any system changes. Below is my working list of limitations, and what you might do about them.
|Limitations and Issues||Developer Action|
|X86 or x64 non-managed binaries, or .NET 4.6.1 only.||Upgrade apps that use older .NET frameworks to 4.6.1 first.|
|Kernel mode stuff not allowed.||If you need that driver, give up!|
|Windows Services not allowed.||If the service is for an updater, remove it. The ISV now just
uploads the new version to the store and users get notified to
If the service really needs system access, give up. Otherwise, the service should probably be redeveloped as a UWP "Background Task".
|Elevation not allowed.||Automatic manifesting a RunAsAdmin is not possible, and must be removed from all exes to be allowed in the store. While it is possible for the end-user to right click using RunAsAdministrator, you can't automate it and the user won't stand for it.|
|UIAccess not allowed.||Automatic manifesting a UIAccess is not possible, and must be
removed from all exes to be allowed in the store.|
I explained to the Microsoft development team why this should be allowed and steps that they would need to take due to system limitations of "well known locations" to make it work. All I can say is that they listened to my concerns. If you need it, you need to add your voice.
|Out-Of-Process COM, COM+, and DCOM not allowed.||Perhaps you can live with an in-process handler? Ultimately, these prohibited items have full system access.|
|Apps cannot expose dlls, in-process COM, or .Net GAC
components to be used by other software.|
This also affects ability to have external plug-ins (or this as plug-in to something else), and Shell Extensions.
|If the other thing that needs access is your own app, you
might need to just build that into this package
Microsoft should be able to solve the Shell Extensions issue at some point, but AFAIK they have made no commitment to do so.
|Apps cannot use DDE to launch external apps.||Maybe you can bring it into the package?|
|Custom "App User Model ID" not supported.||See if you can just remove it.|
|App cannot modify HKLM at runtime.||You can include HKLM settings in your package, but the user
cannot make changes to the values (they are effectively read
Move everything to HKCU.
|Current working directory is wrong.||The current working directory for your app will not be the
folder that the exe is in. It will be the system32 (or SysWow6432)
subfolder under Windows.|
You may need to add a registry item containing the installed folder as a registry string (if you don't have one already) and reference that in your code.
|App cannot write to current working directory.||Due to the above, that folder is read only.|
Use the fix above.
|Certain C++ linking options not supported.||See Microsoft documentation (blogs) on what isn't supported. You'll need to change your linker options in the build.|
|Shortcuts cannot have command line
Keep in mind that with AppX launching, end users cannot add or modify command line arguments themselves either.
|If you need these, you will have to build something extra into
your package. It could be a small launcher program or cmd script.
The launcher/script runs whatever is the target of your current
shortcut with arguments, and you make this launcher/script the new
target of the shortcut.|
If end users need to control these arguments, you'll need to make changes to allow that through program settings, probably stored in the registry.
|App/Shortcut Icons may not have transparency.||Check your icons and use solid backgrounds rather than transparency. Beyond what you do inside the AppX, expect to need multiple copies that are much larger for when you get to the App Store submission. You probably want to start with a 400x400 and shrink down.|
|Certain VC Runtime dependencies need added directly into the package.||See Using Visual C++ Runtime in Centennial project blog post.|
|Will not work on phones (including Windows Phone), Operating Systems from other vendors, Windows 10 original or prior OSs.||Talk to your boss and make sure they understand this.|
I am pretty sure that this list is incomplete. While I have not tested limitations on these other key app interfaces, I suspect them to be an issue:
- App Paths
- Software Clients
- System Environment Variables
- Event Log Message File Formatting
- Windows Scheduled Tasks
- WMI Providers
Key app interfaces that appear to be in place include:
- File Type Associations
- Shell Integrations (just not Shell Extensions)
- Protocol Handlers
- Application Capabilities/Registered Applications (except for search)
- User Environment Variables
One final concern to consider is that, especially on Win 10 tablets, users do not save work and close the application as much. Adding a UWP front end that detects app suspension and saves off state will make the Bridge App work more like a UWP.
Ultimately I am not sure that Desktop Bridge will provide valuable revenue for software vendors to justify the work involved. It really only makes sense, especially considering the limited business market for it right now, for companies committed to fully converting to UWP to gain experience. Personally I'd spend that investment in building an App-V 5 package release instead.