Skip to main content

App-V 5.0 OS Integration - Part 1 - Package Format

In this series of posts I am going to take you behind the scenes of how our packages integrate with our operating system in App-V 5.0.
The most logical place to start is with the package itself and understanding what is output by our Sequencer.
Let’s take this Paint.NET package and try to understand how it is made up.

report.xml

This file is carried over from our 4.6 SP1 days and contains diagnostic and advisory items around our sequenced package such as any warnings or errors encountered during sequencing or any files that have been excluded.

<PackageName>_UserConfiguration.xml

This file is for user specific changes that can be influenced at the time of publishing a package to a user. For example if we want to deploy a package with different shortcuts or a specific script to a certain group of users.

<PackageName>_DeploymentConfiguration.xml

Similar to the above however this file is for global changes that can be influenced at the time of publishing a package. For example if we want to deploy a package with standard set of shortcuts or a particular script to all users.

<PackageName>.msi

The subject of much misconception, this file is not a standalone installer in its own right, it still requires the following .appv file. The .msi will walk users through an installation which essentially will run the PowerShell cmdlets to add the package to the App-V Client in standalone mode.

<PackageName>.appv

Saved the best till last, this is our actual package itself. This one file is enough to publish and deploy our package. It contains our applications assets similar to the .sft we had in App-V 4.x but the file format is not so mystic. The .appv format is a container, built off the .appx format (based on the OPC standard) which forms Windows 8 store applications. This means often we can copy and rename the .appv to zip to explore the contents, this is not a supported method of viewing or changing the actual package so please beware.
When we view the inside of .appv we find some really interesting files and folders, lets call some out:

StreamMap.xml

I have previously mentioned this file in my blog around Feature Block 0 - The Publishing Feature Block. It essentially contains how we have optimised the stream of our package and which files are required at which points.

PackageHistory.xml

This file is like the passport for the package and contains lots of informational items around its origins. For example in here we can find which user sequenced the package, on which machine and at what time. There are lots of other useful pieces of historical information stored inside this file.

FilesystemMetadata.xml

This file contains a list of the files that were captured and make up the package, alongwith the attributes of these files.

AppxManifest.xml

This file is the metadata for the package and contains everything we need to publish it. For example not only does it contain the names/GUIDs associated with our package but it also contains things like the file type associations and shortcuts.

Registry.dat

Now this file is exactly what you think it is! It is a mountable .dat file containing the registry that was captured as part of the package. To browse this file you can copy it out and mount it in regedit under HKLM.

Root

Now we know how the registry is stored, Root is where we can find the file system. Here we can browse the files that were captured in our package right down to the executable itself.
Now we understand the composition of our App-V 5.0 packages take a look at part two where I will be talking about the File System Cache on the client operating system.

Author: Thamim Karim
Labels:

Comments

Post a Comment

Popular posts from this blog

Remove previous versions using MSI Upgrade Table

There are several methods to uninstall the existing older versions of an application e.g. Script, MSI upgrade table, SCCM deployment conditions. We are here discussing the method using Upgrade table. Upgrade table can be used effectively to detect and uninstall the previous versions of a MSI based application provided the upgrade code is known. Here is an example on populating Upgrade Table: Locate the U pgradeCode in Property Manager . Remember this could either be same or different in previous version and if it is different then grab the code from previous version. Go to the Upgrade Table in Direct Editor . Copy the upgrade code to its column. Populate the Version columns based on requirement (consider all the digits as per previous MSI versions). Attribute column needs to be configured with appropriate bit flag for corresponding upgrade behavior. Refer to  Upgrade Table  to calculate the proper bit flag. In example, 768 is the sum of 256+512 which m...
1 comment
Read more

Active Setup Registry Key : What it is and how to create in the package using Admin Studio Install Shield

While launching from Admin account or doing “Run as Admin” it was launching properly but when launched from the standard-user account, though it was launching but GUI was not coming properly and before launching, it throws the error that some particular Skin file is missing. I checked in installation folder and skin file was there but still while launching I was getting the error, but when launched from Admin account or using “Run as admin” it was launching properly with proper GUI and no skin file missing error. On exploring further I found that application was installed by admin account and it created some entries in HKCU, and these entries contain the path and name of skin file to be used. So when we launched the application from Standard user account then these entries were empty in HKCU for Standard user. So to solve this problem while re-packaging I used Active Setup . Active Setup provides a great solution for installing current user data when the package is not installed ...
1 comment
Read more

Using the CorrectFilePaths Shim to Redirect Files on Windows Vista

The last time around , I suggested that you avoid using the acredir.dll shims - RedirectRegistry and RedirectFiles. As alternatives, I recommended VirtualRegistry and CorrectFilePaths. Of course, I have already gone into some details on how to use VirtualRegistry to achieve that, but I haven't gone in to any details on CorrectFilePaths yet. And, unfortunately, the documentation isn't much help as of the 5.0.1 release (as I said - stay tuned to the documentation for future releases, as this is something we are working on). In fact, here is all that the documentation tells you: "Corrects file paths that changed between Windows 95 or Windows 98 and Windows XP Professional. This compatibility fix works by converting the file paths to the correct location for Windows XP Professional in the APIs. For example, a Windows 95 path of C:\Windows\Write.exe is converted to C:\Windows\System32\Write.exe." While this is true, it is not comprehensive (and is, theref...
Post a Comment
Read more