Following on from my post App-V 5.0 OS Integration - Part 1 - Package Format where we talked about how a App-V 5.0 package is made up, now we can move on to look at how this package is reflected on your client operating system after the package has been delivered in terms of file system and cache.
Cache
When App-V 5.0 packages are delivered by default they are stored in %ProgramData%\App-V, this is the physical cache location. In here we will find folders labelled with the GUID of the packages they contain.
To easily find what our package GUID is we can use the Get-AppvClientPackage command, wildcards are great to return a filtered result, and for example here I am searching for Paint.NET:
We can see Paint.NET has a package GUID starting with CA43, if we drill into this folder we are faced with another GUID!
This is our version GUID, as we only have one version of this package published at present there is only one folder. If we go into this folder we see a very familiar sight:
Well familiar enough for anyone who knows about the App-V 5.0 package format as discussed in Part One of this series. Here we can see the key files of our .appv outputted by our sequencer. Our .xml documents contain all the metadata and our Registry.dat file which we will look at in more detail in Part 3 of this series.
Drilling down into the root folder we can see our package files in clear view:
This is a refreshing view compared to the sftfs.fsd cache file we had with App-V 4.6 where things weren’t natively browsable. You will also noticed that some of the files have an X symbol next to them, indicating they are sparse files and not yet streamed. This is because this package has just been published and not yet streamed, at present only the Publishing Feature Block – FB0 is present.
After triggering a stream of the package, we will find these files get streamed locally and become fully present, remember if we don’t this behaviour we can put our client into Share Content Store Mode.
One point to note is the cache will not be cleared after an unpublish, it must be removed, read this KB for more details.
Shortcuts
So now we understand how our package sits on our client, let’s look at how it runs, if we right click our App-V 5.0 shortcut we will notice two things:
1. We call the .exe directly
2. We call it from %LOCALAPPDATA%
So you might thinking, why does the package launch from this location when we already discussed how the package sits physically in %PROGRAMDATA%\App-V?
Well at first glance it would appear we are duplicating the cache for the user we have published to however that isn’t the case. IF we go a few levels up in the folder structure we can see that the folder structure is made up out of symbolic links back to our %PROGRAMDATA% location!
Right, now we understand how our file system works on your client, look out for Part 3 of this series where we will talk about the registry.
Author: Thamim Karim
Comments
Post a Comment