Fix for MSI packages created with App-V 5.0 SP1


So, having just started a project where I get to use App-V 5 outside of the lab environment, this of many posts I plan to make regarding v5, hopefully some of you may find it useful!

The MSI packages created by the 5.0 SP1 sequencer refuse to install on the client, showing the following in the MSI log:

Error: could not load custom action class Microsoft.AppV.MsiTemplate.CustomActions.CustomActions from assembly: AppVMsiPackageTemplate

Using InstEd, I generated a transform between a 5.0 and similar 5.0 SP1 package. I then stripped out all of the application-specific entries to be left with just a couple of changes to the binary table. These hold the custom action dlls responsible for the error above.

To use this, just append the following to your msiexec command line:

msiexec /i package.msi /qb TRANSFORMS=AppV5_MSI_Fix.mst

Using InstEd/Orca or similar, you can also save a transformed version if you don’t want to mess about with command lines.

Use this at your own risk! Whilst everything appears to work fine so far, this is unsupported by Microsoft. I suspect that all the dlls are doing is running Powershell commands to import the package, and as far as I know these haven’t changed, so you should be ok.

Click here to download the MST.



Sebastian Gernert, App-V issue escalation engineer at Microsoft, has posted an alternative solution on his blog which involves adding a couple of registry keys to the client:

Or if you don’t speak German:

4 responses on “Fix for MSI packages created with App-V 5.0 SP1

  1. Pingback: SCCM – Deploy AppV 5.0 SP1 .msi Fix |

  2. Dan,

    We applied the transform and extracted both the before and after x64 custom action. After extracting with 7zip and decompiling with Reflector, I don’t see any code changes other then the assembly info going from 5.0.1104.0 to Am I missing something?

  3. Well that seems to indicate that the fix is safe to use if the code is exactly the same! I suspect the updated version hasn’t been signed properly, hence the Microsoft fix being to apply an exception for this assembly to bypass strongname verification.

    I was using the MSI packages for testing at first but am now using my own Powershell scripts instead – I’ll share these soon!

  4. I’m new to AppV but I took what I’ve learned about the powershell cmdlets and wrote my own pattern. I use’d WiX and DTF to create a merge module that acts as a reusable helper. I then use WiX to create another merge module to contain the appv file and merge both MSM’s into a WiX MSI and presto, it all works beautifully. Not sure if I’ll use this or simply use SCCM 2012 to manage the APPV deployment but it was a good thought exercise at the least.

Leave a Reply