Applications that are sequenced through the App-V 5.0 SP1 sequencer may not be installed correctly

View products that this article applies to.

Symptoms

Applications that are sequenced through the Microsoft Application Virtualization 5.0 Service Pack 1 (App-V 5.0 SP1) sequencer may not be installed correctly when you try to add the package by using the generated MSI. The MSI setup starts, continues, and then exits without generating an error message. Additionally, a generic event that resembles the following will be logged in the Application log:

Note MsiInstaller 1033 events that have a status code of 1603 are generic and only indicate an installation failure. You must collect MSI logs to definitively identify this scenario. For information about how to do this, see the "More Information" section.

↑ Back to the top

Cause

This error occurs because MSIs that are generated by the App-V 5.0 SP1 sequencer include a version of AppVMsiPackageTemplate.dll that is not strongname signed. This is a known issue with App-V 5.0 SP1.

Note This issue does not occur with App-V 5.0 RTM or with any version of the 32-bit App-V 5.0 sequencer.

↑ Back to the top

Workaround

Workaround 1: Use the 32-bit sequencer to create MSI packages to be run on 64-bit operating systems

For 32-bit applications, you can use the 32-bit (x86) App-V SP1 Sequencer to create 64-bit (AMD64) packages. These will run on 64-bit client operating systems in WOW mode.

Workaround 2: Use the 5.0 RTM version of the 64-bit sequencer to package 64-bit

Packages that are created by using the RTM version of the 64-bit Sequencer are fully supported on App-V 5.0 SP1 and SP2 clients.

Workaround 3: Install the package manually

The generated .appv package is still a valid installation package. The package can be installed by running the following Windows PowerShell cmdlets:

Add-AppvClientPackage
Publish-AppvClientPackage

For more information about these cmdlets, go to the following Microsoft website:

Administering App-V using PowerShell

Workaround 4: Turn off strongname signing for AppVMsiPackageTemplate.dll

Another alternative is to trust the assembly and enable the client operating system to install the package even though AppVMsiPackageTemplate.dll is not strongname signed. To do this, import the following Windows Registry Editor Version 5.00 registry keys on the client:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\*,31bf3856ad364e35
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\*,31bf3856ad364e35

↑ Back to the top

More Information

To definitively identify this scenario, enable verbose MSI logging on the client. To do this, add the following Windows Registry Editor Version 5.00 registry view:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer
"Logging"="voicewarmupx"

For more information about how to enable MSI logging, click the following article number to view the article in the Microsoft Knowledge Base:

223300 How to enable Windows Installer logging

A verbose MSI log will contain an error that resembles the following:

SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI250D.tmp-\

SFXCA: Binding to CLR version v4.0.30319

Calling custom action AppVMsiPackageTemplate!Microsoft.AppV.MsiTemplate.CustomActions.CustomActions.PublishPackage Error: could not load custom action class Microsoft.AppV.MsiTemplate.CustomActions.CustomActions from assembly: AppVMsiPackageTemplate System.IO.FileLoadException: Could not load file or assembly 'AppVMsiPackageTemplate, Version=5.0.1104.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) File name: 'AppVMsiPackageTemplate, Version=5.0.1104.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)

The Zone of the assembly that failed was:

MyComputer at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.AppDomain.Load(String assemblyString) at Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionMethod(Session session, String assemblyName, String className, String methodName)

↑ Back to the top