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.
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.
Workaround 1: Use the 32-bit sequencer to create MSI packages to be run on 64-bit operating systemsFor 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-bitPackages 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 manuallyThe generated .appv package is still a valid installation package. The package can be installed by running the following Windows PowerShell cmdlets:
Workaround 4: Turn off strongname signing for AppVMsiPackageTemplate.dllAnother 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:
For more information about how to enable MSI logging, click the following article number to view the article in the Microsoft Knowledge Base:
A verbose MSI log will contain an error that resembles the following:
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)
ID do Artigo: 2876368 - Última Revisão: 06/08/2013 - Revisão: 1