App-V 5 – COM Mode Functionality

Hi all,

Following on from my colleagues post about COM Mode it would be good to understand how COM Mode actually works when you deploy an App-V 5 package with COM Mode set to “Integrated” or “Isolated”.

I’m going to be using an application called Microsoft MapPoint 2004 to show how this works on the client.


The first question is what is COM Mode and its functionality? COM is a registry based subsystem which provides an interface for applications to interact with an object whether it be an EXE or DLL.

“Each COM class is identified by a CLSID, a unique 128-bit GUID, which the server must register. COM uses this CLSID, at the request of a client, to associate specific data with the DLL or EXE containing the code that implements the class, thus creating an instance of the object.”

All COM classes are stored in the registry “HKEY_LOCAL_MACHINE\SOFTWARE\Classes”.

If you view the Virtual Registry for the package you will see that MapPoint has a COM entry and a CLSID specified which means applications can interact with it via a COM Call.


If you then browse to the CLSID specified above, you will see the “LocalServer32” is set to point to MapPoint.exe.


So that’s a COM object captured during the sequencing process but what happens when you deploy the package to your machine?

The first thing to remember is that App-V 5 is an isolation technology which means by default, when you sequence an application COM Mode functionality will be set to “Isolated” which means the CLSID won’t be written to the local operating system.


You can also see this setting in your “_DeploymentConfig.xml” file.


Once you have added your package and deployed it to the machine you will see the following entry in the “native” registry. Note the CLSID reference isn’t set / available.



If your testing COM Mode functionality for your application there is a PowerShell command that you can use to load / test the COM Object:

New-Object -ComObject MapPoint.Application

If you run the command in a PowerShell window, as the package is set as “Isolated” then the COM call fails.


Let’s see what happens when you change the COM Mode functionality in the “_DeploymentConfig.xml” to “Integrated” and be aware I’ve left “OutOfProcessEnabled” and “InProcessEnabled” to false on purpose.


You will see exactly the same as the package being “Isolated” no CLSID for the package because we don’t integrate COM into the OS until “OutOfProcessEnabled” is set to true.


Now I’ve changed the configuration file for OOP to "true", so what happens on the Operating System?


The CLSID is now set in the “native” registry which means you can manipulate it via a COM Object call.


If you run the same command as above the COM object call from PowerShell now works.


If you look in Task Manager you will see the MapPoint.exe process running but no GUI available to the user.


So MapPoint.exe is loaded, what can you do with the object? You can see below the object can be manipulated and MapPoint methods can be used to “OpenMap” etc.


Hope this shows how COM integrates from an App-V 5 Package sequence to a client deployment.

David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

Comments (1)

  1. Trentent says:

    1) If you have COM set to Isolated, but open regedit in the bubble of your app (/appvve) will the COM objects be exposed to that bubble?
    2) If you create the COM object in an ‘integrated’ scenario, do you get ‘moved into the bubble’ automatically (like launching a .exe in the packageinstallationroot path)?

Skip to main content