Apr 10, 2013 - 5 Comments - Virtual Vibes -

App-V 5.0 OS Integration – Part 3 – Registry

Now we understand the package format and client file system for App-V 5.0, let’s take a look out how the registry looks in terms of OS integration.

As mentioned in Part 1 of this blog series, within the .appv package we can see a registry.dat file which contains the entire registry that was captured for the particular package.

zip

Also as discussed in Part 2 we can also see that the registry.dat sits in the cache location on the client once the package has been delivered.

Package

So what actually happens with this registry hive? Well it gets mounted and there twos views of this, native and virtual….

Native Registry

Gone are the days when we have to break into the bubble to see an App-V applications registry, similar to the file system cache, we store assets in natively to windows standards. The only difference is the physical registry location is not stored directly in HKEY_LOCAL_MACHINE\SOFTWARE but rather HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages.

regedit

In this location we can see a reference by GUID to all of our packages. For example below I have drilled down into Paint.NET:

regedit2

The exact same concepts exist for HKEY_CURRENT_USER\Software for all App-V 5.0 packages. So that’s the native registry, plain to see on the local machine but how does the application itself see itself in registry?

Virtual Registry

The virtual view of registry is a much more simplistic view in that the application sees itself exactly where it was sequenced to, HKEY_LOCAL_MACHINE\SOFTWARE.

regedit3

When we pan native and virtual views of HKEY_LOCAL_MACHINE\SOFTWARE next to each other we can clearly see the difference.

regedit4

Again the same principles exist for HKEY_CURRENT_USER\Software but we will talk about that more in Part 4 where we will discuss state changes.

App-V 5.0 OS Integration

Part 1 – Package Format

Part 2 – File System Cache

Part 3 – Registry

Part 4 – State Changes