64-bit Managed Custom Actions with Visual Studio
2013-01-08 16:17
267 查看
A reader who happened across my post on Windows Installer on 64-bit Platforms mentioned a
problem with running 64-bit managed custom actions using the Visual Studio 2005 Windows Installer project. This also recently cropped up in an internal discussion alias.
The issue is that if you build a managed class library project targeting a 64-bit platform using
a 64-bit machine a
shim packaged with the .msi file is a 32-bit executable.
Let's step back a minute, though, to how to build a Windows Installer setup project with managed custom actions. I won't go into details,
but basically you create a new Class Library project that contains one or more derivatives from the
In the Custom Actions editor for your Windows Installer project you can right-click on a specific phase (Install, Commit, Rollback, or Uninstall) or, preferably, the root node (which adds the custom action to all phases with the appropriate custom action types)
and add whatever you want from project output to a specific file in your file system. If your class library is in the same solution I recommend clicking "Add Output" in the custom action editor dialog.
You should also click on the Windows Installer project and change the TargetPlatform property to either x64 or Itanium, depending on what you're targeting. This makes sure that 64-bit components are installed to the 64-bit folders
like [ProgramFiles64Folder]. If you don't set this according to what binaries you're installing (which can be a mix of both 32- and 64-bit) 64-bit files will be installed into [ProgramFilesFolder] which, on 64-bit platforms, is, for example, C:\Program
Files (x86).
Back to the problem. When you build the Windows Installer project in Visual Studio 2005 it embeds the 32-bit version ofInstallUtilLib.dll into the Binary
table as InstallUtil. When Windows Installer executes your managed custom action it actually is calling the
1 deferred custom action (1025) which creates an instance of the CCW
runs your
To workaround this issue you either need to import the appropriate bitness of InstallUtilLib.dll into the Binary table for the InstallUtil record or - if you do have or will have 32-bit managed custom actions add it as
a new record in the Binary table and adjust the CustomAction table to use the 64-bit Binary table record
for 64-bit managed custom actions.
To replace the 32-bit InstallUtilLib.dll with the 64-bit bitness,
Open the resulting .msi in Orca from the Windows Installer SDK
Select the Binary table
Double click the cell [Binary Data] for the record InstallUtil
Make sure "Read binary from filename" is selected and click the Browse button
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727
Select InstallUtilLib.dll
Click the Open button
Click the OK button
Note that the Framework64 directory is only installed on 64-bit platforms and that it corresponds to the 64-bit processor type. That is, you won't find the x64 flavor of InstallUtilLib.dll on an IA64 machine.
If you already have or anticipate having 32-bit custom actions in future patches - and I recommend this approach because the future is difficult to predict - you should add a new record.
Open the resulting .msi in Orca from the Windows Installer SDK
Select the Binary table
Click the Tables menu and then Add Row
Enter, for example, InstallUtil64 for the Name
Select the Data row and click the Browse button
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727
Select InstallUtilLib.dll
Click the Open button
Click the OK button
Select the CustomAction table
For each custom action where the Source column is InstallUtil and only those custom actions that are 64-bit managed custom actions (or that were built with
64-bit custom actions), change the value to, for example, InstallUtil64
This only affects DLLs build with
Referenced from: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
problem with running 64-bit managed custom actions using the Visual Studio 2005 Windows Installer project. This also recently cropped up in an internal discussion alias.
The issue is that if you build a managed class library project targeting a 64-bit platform using
/platform:x64or
/platform:Itaniumand install a Windows Installer package built in Visual Studio 2005 on
a 64-bit machine a
System.BadImageFormatExceptionis thrown. The reason is because the native
shim packaged with the .msi file is a 32-bit executable.
Let's step back a minute, though, to how to build a Windows Installer setup project with managed custom actions. I won't go into details,
but basically you create a new Class Library project that contains one or more derivatives from the
System.Configuration.Install.Installerclass.
In the Custom Actions editor for your Windows Installer project you can right-click on a specific phase (Install, Commit, Rollback, or Uninstall) or, preferably, the root node (which adds the custom action to all phases with the appropriate custom action types)
and add whatever you want from project output to a specific file in your file system. If your class library is in the same solution I recommend clicking "Add Output" in the custom action editor dialog.
You should also click on the Windows Installer project and change the TargetPlatform property to either x64 or Itanium, depending on what you're targeting. This makes sure that 64-bit components are installed to the 64-bit folders
like [ProgramFiles64Folder]. If you don't set this according to what binaries you're installing (which can be a mix of both 32- and 64-bit) 64-bit files will be installed into [ProgramFilesFolder] which, on 64-bit platforms, is, for example, C:\Program
Files (x86).
Back to the problem. When you build the Windows Installer project in Visual Studio 2005 it embeds the 32-bit version ofInstallUtilLib.dll into the Binary
table as InstallUtil. When Windows Installer executes your managed custom action it actually is calling the
ManagedInstallentry point function from InstallUtilLib.dll as a type
1 deferred custom action (1025) which creates an instance of the CCW
System.Configuration.Install.IManagedInstallerinterface and
runs your
Installerclasses. Since the native InstallUtilLib.dll is 32-bit it loads the 32-bit Framework which will throw the
BadImageFormatExceptionsince your managed class library is 64-bit.
To workaround this issue you either need to import the appropriate bitness of InstallUtilLib.dll into the Binary table for the InstallUtil record or - if you do have or will have 32-bit managed custom actions add it as
a new record in the Binary table and adjust the CustomAction table to use the 64-bit Binary table record
for 64-bit managed custom actions.
To replace the 32-bit InstallUtilLib.dll with the 64-bit bitness,
Open the resulting .msi in Orca from the Windows Installer SDK
Select the Binary table
Double click the cell [Binary Data] for the record InstallUtil
Make sure "Read binary from filename" is selected and click the Browse button
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727
Select InstallUtilLib.dll
Click the Open button
Click the OK button
Note that the Framework64 directory is only installed on 64-bit platforms and that it corresponds to the 64-bit processor type. That is, you won't find the x64 flavor of InstallUtilLib.dll on an IA64 machine.
If you already have or anticipate having 32-bit custom actions in future patches - and I recommend this approach because the future is difficult to predict - you should add a new record.
Open the resulting .msi in Orca from the Windows Installer SDK
Select the Binary table
Click the Tables menu and then Add Row
Enter, for example, InstallUtil64 for the Name
Select the Data row and click the Browse button
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727
Select InstallUtilLib.dll
Click the Open button
Click the OK button
Select the CustomAction table
For each custom action where the Source column is InstallUtil and only those custom actions that are 64-bit managed custom actions (or that were built with
/platform:anycpu, the default, where you want to run as
64-bit custom actions), change the value to, for example, InstallUtil64
This only affects DLLs build with
/target:library. Managed EXEs will run correctly according to what platform they target.
Referenced from: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
相关文章推荐
- How to compile a C/C++ DLL for 64 bit with Visual Studio?
- USING OPENCV 2.4.2 WITH VISUAL STUDIO 2012 ON WINDOWS 7 (64-BIT)
- Debugging 64-bit applications using Visual Studio 2005
- Create custom Task List and Forms in SharePoint 2010 with Visual Studio 2012
- Deploying COM Add-ins for 64-bit Office using Visual Studio (Saaid Khan for Nathan Halstead)
- Deploying Silverlight to a Custom List with Visual Studio 2010
- Building Python 2.7.10 with Visual Studio 2010 or 2015 - Google Chrome
- Mastering Web Development with Microsoft Visual Studio 2005
- Deploy custom Css,Js files in SharePoint 2010 using visual studio 2010
- 项目管理实践【六】自动同步数据库【Using Visual Studio with Source Control System to synchronize database automaticall
- 一步一步学习sharepoint2010 workflow 系列第三部分:自定义SharePoint代码工作流 第8章 自定义Visual Studio工作流(Custom Visual Studio workflows)
- NVIDIA Nsight Visual Studio Edition 3.0 Final with OpenGL Debugging and Kepler GK110 support!
- Domain-Specific Development with Visual Studio DSL Tools
- Visual debugging with RStudio
- visual studio setup project custom action ole calls and show dialog support
- How to create a project with existing folder of files in Visual Studio?
- error: Python was built with Visual Studio 2003
- Load testing with Visual Studio Ultimate
- How to connect to MySQL database from Visual Studio VS2010 – problems with NET connectors
- Selenium 2.0 WebDriver with Visual Studio, C#, & IE