从InstallShield调用C#自定义操作时遇InstallShield.Interop.Msi加载失败错误

Hey there, let's work through this assembly loading issue together— I’ve dealt with similar headaches with InstallShield interop assemblies before, so here are some practical steps to get your custom action running smoothly again:

• Verify the "Copy Local" property for your reference
  Right-click the InstallShield.Interop.Msi reference in your project, go to Properties, and make sure the Copy Local option is set to True. Sometimes this setting gets reset accidentally, which means the DLL won’t be copied to your output directory automatically. Even if you manually placed it there, the installer project might not pick it up unless this flag is enabled.

• Ensure the DLL is included in your installer project
  Open your installer project, navigate to the File System view, and double-check that InstallShield.Interop.Msi.dll is explicitly added to the same Application Folder as your managed assembly. If you just copied the DLL manually outside the project, the installer might not have included it in the package— drag-and-drop it into the folder in the installer project to confirm it’s part of the build.

• Check platform and version compatibility
  Since this worked before, it’s worth checking if something changed with versions or platform targeting:

  • Is the InstallShield.Interop.Msi.dll version you’re using now different from the one in your previous working setup? Mismatched versions can cause loading failures.
  • Does your managed assembly’s target platform (x86/x64/Any CPU) match the interop DLL? InstallShield’s interop components are often 32-bit, so if your assembly is set to Any CPU and runs on a 64-bit system, it might fail to load the 32-bit DLL. Try switching your project’s target platform to x86 and rebuild.

• Add assembly binding redirects (if version mismatches exist)
  If there’s a version discrepancy between the interop DLL referenced in your project and the one deployed, add a binding redirect to your application’s config file (or the installer’s config):

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="InstallShield.Interop.Msi" publicKeyToken="INSERT_PUBLIC_KEY_TOKEN" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-YOUR_OLD_VERSION" newVersion="YOUR_CURRENT_DLL_VERSION" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  

  You can get the public key token and version number by using the ildasm.exe tool on the DLL to inspect its metadata.

• Adjust the custom action’s execution context
  Installer custom actions run under different contexts, and permission issues can sometimes block DLL loading. Try changing your custom action’s Execution Context from No Impersonation to Impersonate (or vice versa) to ensure the process has access to the folder where the DLL is located.

• Enable assembly loading logging for deep debugging
  If none of the above works, use the Assembly Binding Log Viewer to pinpoint exactly where the load is failing. Open an elevated Command Prompt and run:

  fuslogvw.exe
  

  Configure it to log all assembly binds, then run your installer again. The log will show the paths the system tried to load the DLL from and why it failed— super helpful for tracking down hidden issues like missing dependencies or incorrect paths.

内容的提问来源于stack exchange，提问作者Ben_G