The Analyzer

Back to tool Introduction.

 Back to tool Documentation of Tool Functions

Back to tool Documentation of Publishing tab

When on the Publishing Tab, you may select a package and then click on the Analyze button to run the Package Analyzer against the App-V package.  The function is also available as a right click option on the package. This will bring up a new window with the Analyzer results.

The Analyzer display provides a wealth of information about your package.  Color coding is used to highlight interesting, warning, and serious issues detected.  The Installer Fixups button provides an interface with additional information about potentially automated fixes that can be created using the PassiveInstall PowerShell module.

Note:  As of version 5.9 of the tool, the pervious "Generate Fixups" button that produced a PowerShell script for the SilentInstall framework has been replaced by this button.  Installer Fixups works with the newer PassiveInstall framework (also available on TMurgent.com under the Packager Tools).

After clicking on the button, you see the different types of potential fixes identified by the Analyzer, and you can choose which ones you want using the checkboxes on the left side of the detail pane.

The right side provides some detail about each of the types, and you may use the expander buttons to reveal/hide the text.  The different types of fixes include:

• Shortcut Target Fixups. If the package contains certain kinds of shortcuts that are known to cause issues in App-V, a fix is offered.
  • Shortcut with CMD or BAT file type as the target. The script would alter the shortcut to use cmd.exe as the target with arguments starting with /c and the filename (followed by any previous arguments).  This fix would use the Set-PassiveShortcutFixupCmdBat cmdlet.
  • Shortcut with REG type as the target. The script would alter the shortcut to the reg.exe as the target with the /i and filename as arguments, along with a force argument. This fix would use the Set-PassiveShortcutFixupReg cmdlet.
  • Shortcut name ending with a space character: A rather famous three letter company has an application that creates a shortcut like this.  This fix would use the Set-PassiveShortcutFixupSpaceAtEnd cmdlet.
• Application Capabilities Registration Fixups. If the package contains one or more File Type Associations and a corresponding Application Capabilities Registration is not present, a fix is offered.  The fix will add this registration, including the automatic generation of ProgIDs if needed. This fix would use a variety of standard PowerShell registry cmdlets plus the New-PassiveRegistryKeyIfNotPresent cmdlet to simplify the script.
• AppPath for Start Menu Search Fixups. Many installers fail to add this registration.  It allows the application to be found when using the Windows Start Menu/Cortana search feature, where the user starts typing the name of an application and it is quickly found.  Without this registration, especially under App-V, the user doesn't find the app.  This fix would use the  New-PassiveAppPathSearch cmdlet.
• Path to AppPath Fixups. App Installers should no longer make changes to the Path variable, but should register an AppPath Path entry to identify additional search folders for dll search on a per-app basis.  On native installs, changing the Path variable tends to break other apps.  Under App-V, the change is isolated so it won't break other apps, but sometimes it breaks this one.  This fix will restore the Path variable and make the AppPath registration for all applications in the package.  This fix would use a variety of standard and Passive cmdlets.
• Policy Key Fixups. When an installer lays down registry keys in the Policy branch in a App-V package, this trumps any distributed by Active Directory Group Policy.  Sometimes this is a good thing and sometimes it isn't.  For when it isn't, this fix will remove them.  If uses the Remove-PassiveRegistryItem and standard PowerShell cmdlets.
• Installer Cache Fixups. The script determines which files in the installer cache may be removed by checking for references to them as Icon or Font sources.  If added to the package and not reference, the script will attempt deletion of them.  The created script understands that some of the files may be randomly generated names that change with each install, and tries to handle that also. It might not be perfect, but it is a pretty good attempt at automation of the cleanup.  The fix would use the Remove-PassiveInstallerCacheFilePattern and Remove-PassiveInstallerCacheFolders cmdlets.
• Service Account Fixups. App-V ignores services set to run under an account other than Local System.  This fix will change the service account.  The service will probably work just fine, but you'll need to test it to be sure. This fix uses the Set-PassiveServiceAccount cmdlet.
• DotNet Compilation Fixups. Installers may forget to compile their .Net components, or you might have ended sequencing before the background compilation it asked for gets to run (which only happens after a significant idle period). This fixup will attempt compilation of any .Net component that is missing the Native Interface compiled version in the installer cache.  Some of these compilations will always fail (usually because the developer listed a missing dependency that isn't actually needed) but it causes no harm.  The fix uses the native ngen engine and always makes sure the ngen queue is flushed at the end.

When you click on the Generate Fix Script button, the tool will generate a PowerShell script that uses the PassiveInstall module to perform the actions.  To get the improved package, you would resequence the package, running that PowerShell script after performing the install as before.

The InstallerFixes in the analyzer don't fix your App-V Package, it helps you make a better replacement package!