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.
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.
So what actually happens with this registry hive? Well it gets mounted and there twos views of this, native and virtual….
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.
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:
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?
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.
When we pan native and virtual views of HKEY_LOCAL_MACHINE\SOFTWARE next to each other we can clearly see the difference.
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.