Back when we created SoftGrid, the OS only supported one “owner” application for a given file type association. And we learned to live with this, but really didn’t like it all that much. Now we don’t have to.
Background on FTA Conflict
For natively installed applications, somewhere along the way Microsoft added a new interface for developers (or more specifically installer developers) to let them install their applications in a way that the file associations references were cumulative. Using this “interface”, and the user would see additional applications as “open with” options, and the user could choose which to take ownership as default action. This “interface” is known by several names, depending on who is doing the talking: “Registered Applications”, “Application Capabilities”, or “Default Programs”.
With App-V 4.* this capability, if used by the installer developer, was simply ignored and we ended up with the FTA last-write-wins scenario. This meant the last virtual app arriving to the user machine with the conflicting FTA won. With distributing the packages via the App-V Server, this meant that the last application package added to the management console always won. But with SCCM delivery you could never really control the order (except via task sequences, and then only for new systems created after the task sequence is created/updated) so different users could get different file associations.
But in App-V 5 the ability to capture and expose “Registered Applications” is implemented fully by App-V, assuming that the person creating the installer did the right thing. But it turns out that very few installer developers bothered to add this new capability into their packages.
This “interface”, is implemented by the installer as a series of optional registry settings.
- It starts by adding a new registry string value under the “HKLM\Software\RegisteredApplications” or “HKCU\Software\RegisteredApplications” key (depending on if the install was per-machine or per-user). The new value name would be a unique name, such as the name of the application. This would be a Reg_SZ that would contain the relative path to another key in the same hive. Typically, this would be “Software\[ProgramName]\Capabilities
- Then add the named key to the registry.
- Under that key, add two Reg_SZ values, called “ApplicationDescription” and “ApplicationName”.
- Also under that key, and a key called FileAssociations
- Under FileAssociations, add values for each supported file association. The value name for each is the file extension, starting with the period (as in “.zip”). The data for the value is the ProgID registered for that file association, which you can find as the default value for the FTA.
The “interface” supports a lot of other capabilities to be added, but these are the ones I am most interested.
How to use this to solve FTA conflict when the developer didn’t
Here is what I do to make these app file associations work the way that they really should have to start with.
Sequence the app normally and get into the sequence editor virtual registry. Look to see if it added anything under the HKLM or HKCU Software\RegisteredApplications.
If not locate the file associations in the virtual registry. They will look like this:
Click on each FTA and look at the ProgID. Some will not have ProgIDs, so skip those. (If anal, you might look for a “open with progid” subkey that will have the progid).
Create a “.reg” file that will create the entries that you need. If the installer added the FTAs under machine, you will use the HKEY_LOCAL_MACHINE hive in this file, otherwise use the HKEY_CURRENT_USER. With App-V, it doesn’t matter which you use because the publishing action at the client moves the keys depending on whether the -Global flag was used. For example, to handle WinZip, I created the following file:
|
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WinZip\Capabilities] [HKEY_LOCAL_MACHINE\SOFTWARE\WinZip\Capabilities\FileAssociations] [HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications] |
Revert your sequencing VM and re-sequence. After completing the install, run the reg file (while in monitoring mode). That’s it.
Results
When the virtual package is deployed, the user can right-click an appropriate file type and have access to all of the registered options. In the image below, the deployed WinZip package is the default action for the .Zip file type, but the native windows explorer handing of zip files remains available.
When the user wants to change the default themselves, they can click on that “choose default program” menu shown above, or go to the Control Panel, Default Programs,
then click on “Associate a file type or protocol with a specific program”. Locate the file type, and they can pick the default from any program that registered itself correctly.
Alternatively, the user can go to the Control Panel, Default Programs,
then click on “Set your Default Programs” and bump a registered application to be the primary (default) for all of it’s registered associations.
Summary
Using this technique, we can easily improve the behavior of applications while virtualizing!
PS: You MSI repackagers could do this also.
