App-V’s Dynamic Suite Composition is a powerful feature in that it allows multiple “bubbles” to share the same virtual environment. In other words, package A can be made dependent on package B. But if DSC is used extensively, dependencies between packages tend to become difficult to manage – there seems to be no simple way of listing all packages’ dependencies. Well, I have written a PowerShell script that does just that.
Using Get-AppVPackageDependencies
Just call the script with the path (UNC or local) to a folder containing packages. The script will recursively search the path given for OSD files and analyze each OSD file for dependencies. Here is some sample output:
PS D:\> .\Get-AppVPackageDependencies.ps1 .\ ============================================================ Dependencies found: ============================================================ DaveSoft_CopyRite_Vista.CopyRite -> Nvu Opera -> Firefox_JRE ============================================================ All packages found: ============================================================ Name GUID ---- ---- Nvu 3AAC7EE6-84C4-4021-966B-56C52FF95AAF WinDirStat 3C5E1C59-D56E-4463-B9A0-5190034E6223 DaveSoft_CopyRite_Vista.CopyRite 4A7697E4-ED02-4D87-A8F0-88D7DEB914DE Firefox_JRE 999E8458-D477-4975-B3C8-3BCE1252B991 Opera 24D14B13-1838-45B2-9DAC-78D0A7432F69
In the example above, the script was located in the same folder as the packages, thus the parameter “.\”.
Get-AppVPackageDependencies – the Script
Here is the source code. Let me know if it is useful to you.
# # Get-AppVPackageDependencies by Helge Klein, sepago GmbH, http://blogs.sepago.de/helge/ # # Usage: # # Get-AppVPackageDependencies <path to folder containing packages> # #Requires -Version 2 param( [ValidateNotNullOrEmpty()] [System.String[]] $PackageBasePath ) # Initialize a hash table that stores GUID -> name associations $Packages = @{} # Get a list of all .OSD files below the base path passed in $SFTFiles = Get-ChildItem $PackageBasePath -filter *.osd -force -recurse # Store each OSD file's data (name and GUID) foreach ($SFTFile in $SFTFiles) { # Read the OSD file [xml] $SFTFileXML = Get-Content $SFTFile.FullName # Store relevant information $PkgName = $SFTFileXML.SOFTPKG.NAME $PkgGUID = $SFTFileXML.SOFTPKG.IMPLEMENTATION.CODEBASE.GUID if ($Packages.ContainsKey($PkgGUID) -eq $false) { $Packages.Add($PkgGUID, $PkgName) } } Write-Output "`n============================================================`nDependencies found:`n============================================================`n" # Process each package's dependencies foreach ($SFTFile in $SFTFiles) { # Read the OSD file [xml] $SFTFileXML = Get-Content $SFTFile.FullName $PkgDependencies = $SFTFileXML.SOFTPKG.IMPLEMENTATION.VIRTUALENV.DEPENDENCIES foreach ($PkgDependency in $PkgDependencies) { # Extract package information (again) $PkgName = $SFTFileXML.SOFTPKG.NAME $PkgGUID = $SFTFileXML.SOFTPKG.IMPLEMENTATION.CODEBASE.GUID # Extract the GUID the package depends on $PkgDependencyGUID = $PkgDependency.CODEBASE.GUID # Look up the depending package's name if ($PkgDependencyGUID -ne $null -and $Packages.ContainsKey($PkgDependencyGUID)) { Write-Output "$PkgName -> $($Packages.Get_Item($PkgDependencyGUID))" } } } Write-Output "`n============================================================`nAll packages found:`n============================================================" Write-Output $Packages | format-table -auto @{Label="Name";Expression={$_.Value}},@{Label="GUID";Expression={$_.Name}}
Download
You can also download a digitally signed version of the script here.
Nice script.
It might boost performance a little, if you store the xml content of each .osd file in a list and iterate that list instead of reading the file content twice.
Hi Holger,
I guess I programmed it like this (not keeping all files in memory) to not limit scalability. Although I admit it would need to be a truly great number of OSD files to reach typical 32-bit process memory barriers (2 GB).
This is a very good script.
I always wondered about this issue. To resolve this, I created a windows application that connects to access database. Application allows users to import the OSD files to this database. Once all the information of OSD files is in database, you can generate any report out of it. Currently I am using this application to perform:
1) check on 8.3 directory names to make sure they are unique before we sequence any app
2) Generate report on Dynamically suited applications. It allows you to select the app and finds the applications that are including this app as DSC.
I would appreciate your thoughts or comments on this approach.
Thanks,
Hitesh
Hi Hitesh,
you used a different approach than I did. While mine is simpler to implement and use you are independent of the actual OSD files on the server. So both have their pros and cons. I your solution works well, stay with it.
Helge