{"id":2483,"date":"2006-02-01T14:48:00","date_gmt":"2006-02-01T14:48:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/heaths\/2006\/02\/01\/64-bit-managed-custom-actions-with-visual-studio\/"},"modified":"2006-02-01T14:48:00","modified_gmt":"2006-02-01T14:48:00","slug":"64-bit-managed-custom-actions-with-visual-studio","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/setup\/64-bit-managed-custom-actions-with-visual-studio\/","title":{"rendered":"64-bit Managed Custom Actions with Visual Studio"},"content":{"rendered":"

A reader who happened across my post on\nWindows\nInstaller on 64-bit Platforms<\/a>\n\nmentioned<\/a> a problem with running 64-bit managed custom actions using the\nVisual Studio 2005 Windows Installer project. This also recently cropped up in\nan internal discussion alias.<\/p>\n

The issue is that if you build a managed class library project targeting a 64-bit platform\nusing \/platform:x64<\/code> or \/platform:Itanium<\/code> and install a\nWindows Installer package built in Visual Studio 2005 on a\n64-bit machine a\nSystem.BadImageFormatException<\/code><\/a> is thrown. The reason is because\nthe native shim packaged with the .msi<\/i> file is a 32-bit executable.<\/p>\n

Let’s step back a minute, though, to how to build a Windows Installer setup\nproject with managed custom actions. I won’t go into\ndetails<\/a>, but basically you\ncreate a new Class Library project that contains one or more derivatives from\nthe\n\nSystem.Configuration.Install.Installer<\/code> class<\/a>. In the Custom\nActions editor for your Windows Installer project you can right-click on a\nspecific phase (Install, Commit, Rollback, or Uninstall) or, preferably, the root node\n(which adds the custom action to all phases with the appropriate custom action\ntypes) and add whatever you want from\nproject output to a specific file in your file system. If your class library is\nin the same solution I recommend clicking “Add Output” in the custom action\neditor dialog.<\/p>\n

You should also click on the Windows Installer project and change the\nTargetPlatform property to either x64 or Itanium, depending on what you’re\ntargeting. This makes sure that 64-bit components are installed to the 64-bit\nfolders like [ProgramFiles64Folder]. If you don’t set this according to what\nbinaries you’re installing (which can be a mix of both 32- and 64-bit) 64-bit\nfiles will be installed into [ProgramFilesFolder] which, on 64-bit platforms,\nis, for example, C:Program Files (x86)<\/i>.<\/p>\n

Back to the problem. When you build the Windows Installer project in Visual\nStudio 2005 it embeds the 32-bit version of InstallUtilLib.dll<\/i> into the\n\nBinary table<\/a> as InstallUtil. When Windows Installer executes your managed\ncustom action it actually is calling the ManagedInstall<\/code> entry point function\nfrom InstallUtilLib.dll<\/i> as a\ntype 1<\/a> deferred custom action (1025) which creates\nan instance of the CCW\n System.Configuration.Install.IManagedInstaller<\/code> interface<\/a>\nand runs your Installer<\/code> classes. Since the native \nInstallUtilLib.dll<\/i> is 32-bit it loads the 32-bit Framework which will throw\nthe BadImageFormatException<\/code> since your managed class library is 64-bit.<\/p>\n

To workaround this issue you either need to import the appropriate bitness of\nInstallUtilLib.dll<\/i> into the Binary table for the InstallUtil record or –\nif you do have or will have 32-bit managed custom actions add it as a new record\nin the Binary table and adjust the\n\nCustomAction table<\/a> to use the 64-bit Binary table record for 64-bit managed\ncustom actions.<\/p>\n

To replace the 32-bit InstallUtilLib.dll<\/i> with the 64-bit bitness,<\/p>\n<\/p>\n

    \n
  1. Open the resulting .msi<\/i> in Orca from the Windows Installer SDK<\/li>\n
  2. Select the Binary table<\/li>\n
  3. Double click the cell [Binary Data] for the record InstallUtil<\/li>\n
  4. Make sure “Read binary from filename” is selected and click the Browse\n\tbutton<\/li>\n
  5. Browse to %WINDIR%Microsoft.NETFramework64v2.0.50727<\/i><\/li>\n
  6. Select InstallUtilLib.dll<\/i><\/li>\n
  7. Click the Open button<\/li>\n
  8. Click the OK button<\/li>\n<\/ol>\n

    Note that the Framework64 directory is only installed on 64-bit platforms and\nthat it corresponds to the 64-bit processor type. That is, you won’t find the\nx64 flavor of InstallUtilLib.dll on an IA64 machine.<\/i><\/p>\n

    If you already have or anticipate having 32-bit custom actions in future\npatches – and I recommend this approach because the future is difficult to\npredict – you should add a new record.<\/p>\n<\/p>\n

      \n
    1. Open the resulting .msi<\/i> in Orca from the Windows Installer SDK<\/li>\n
    2. Select the Binary table<\/li>\n
    3. Click the Tables menu and then Add Row<\/li>\n
    4. Enter, for example, InstallUtil64 for the Name<\/li>\n
    5. Select the Data row and click the Browse button<\/li>\n
    6. Browse to %WINDIR%Microsoft.NETFramework64v2.0.50727<\/i><\/li>\n
    7. Select InstallUtilLib.dll<\/i><\/li>\n
    8. Click the Open button<\/li>\n
    9. Click the OK button<\/li>\n
    10. Select the CustomAction table<\/li>\n
    11. For each custom action where the Source column is InstallUtil and only those\ncustom actions that are 64-bit managed custom actions (or that were built with \/platform:anycpu<\/code>,\nthe default, where you want to run as 64-bit custom actions), change the value\nto, for example, InstallUtil64<\/li>\n<\/ol>\n

      This only affects DLLs build with \/target:library<\/code>. Managed EXEs will run\ncorrectly according to what platform they target.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

      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 […]<\/p>\n","protected":false},"author":389,"featured_media":3843,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[4,14,20],"class_list":["post-2483","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-64-bit","tag-development","tag-installation"],"acf":[],"blog_post_summary":"

      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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/2483","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/users\/389"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/comments?post=2483"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/2483\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media\/3843"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media?parent=2483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/categories?post=2483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/tags?post=2483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}