我正在一个基本的 MSI (installshield 2014) 项目中创建一个新的自定义操作。我必须在abc.dll作为产品部署的一部分部署的托管 .Net 程序集中调用公共方法。abc.dll是组件的一部分，该组件是设置设计component1中功能的一部分。feature1
当我尝试在自定义操作创建向导中引用该程序集时，我提到它Location为Installed with the product. 但是，Action Parameters当我尝试浏览abc.dll部署路径时，在自定义操作创建向导的步骤中，我看不到它：
虽然我可以abc.dll在组件中浏览它时看到它，如下面的快照所示。它abc.dll作为其中的一部分component1被部署在%programfiles%产品的路径中。
另一方面，我可以在自定义操作创建向导中看到一个pqr.exe文件（它被部署为另一个组件的一部分component2），如下面的快照所示：
谁能指导我为什么会发生这种情况？
我终于解决了我的问题。这一切都归结为 Installshield 如何处理 .Net 程序集及其依赖项的打包。
Installshield 引用 .Net exe 及其依赖项的方式之间的区别：
每当您添加主项目输出时，例如pqr.exe在我的情况下，它就会被添加到组件中。当您浏览您的组件时，您将根据 installshield 环境的标准已知变量（例如等）在Link To列下看到 exe 的源路径。[InstallDir]\ComponentName\
现在，当 installshield 必须创建用于部署 .Net 程序集的 MSI 包时，例如pqr.exe在我的情况下，它还尝试打包其依赖项以进行部署。就我而言prq.exe，取决于abc.dll. 但需要注意的是 installshield 不会在其自己的*.ISM安装程序项目文件中静态维护 .Net 程序集的依赖项列表。
所以abc.dll也显示在组件中，但它的路径是作为 ISM 文件正在构建的磁盘上的完全限定路径，例如D:\mywork\MSIProject\. 这是因为abc.dll它实际上不是 ISM 安装程序项目文件的一部分。其实我用文本编辑器打开了xml格式的ISM文件，试着搜索了abc.dll一下，根本没有。因此abc.dll不作为要在 ISM 安装程序定义文件中部署的程序集存在。但只有在构建 ISM 文件时，它才会尝试将所有依赖项与 *.exe 文件一起打包。
所有依赖项都应该存在于 *.exe 文件所在的同一根目录中，否则 installshield 将无法打包它们。
installshield 如何打包 .Net exe 及其依赖项之间的区别：
另一个需要注意的区别是，如果您pqr.exe从构建 ISM 文件的磁盘路径中删除，则 ISM 文件将无法构建，但如果您删除abc.dll（这不是 ISM 定义文件的物理部分，因为它只是一个参考/依赖项），那么 ISM 文件仍将成功构建。
installshield 中的自定义操作如何引用 .Net exe 及其依赖项之间的区别：
就我的实际问题而言，您只能在自定义操作中直接引用那些作为组件一部分的程序集。您不能引用逻辑上看起来像组件的一部分的程序集（因为它们是依赖项），但实际上它们只是因为它们是托管 .Net exe 文件的依赖项而显示在那里。
我假设 InstallShield 正在验证这些二进制文件是否可以作为自定义操作调用。可执行文件可以作为自定义操作运行，因此它会显示出来。除非导出具有所需签名的入口点，否则不能任意调用 Dll。Windows Installer 不支持调用托管代码自定义操作，因此 InstallShield 可能提供了一个 C++ shim 来调用（就像 Visual Studio 安装程序项目一样）。否则 C++ Dlls 需要有这个签名：
UINT__stdcall CustomActionEntryPoint(MSIHANDLE hInstall)
这里的例子：
https://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup-projects-and-custom-actions/
https://www.codeproject.com/Articles/570751/DevMSI-An-Example-Cplusplus-MSI-Wix-Deferred-Custo
正如我所说，您的 IS 版本可能支持在调用 Dll 的其他一些描述下调用托管代码 Dll（与“调用标准 Windows Installer 自定义操作”之类的内容相反）。