VB.NET（.NET Framework 4.8）SmartPlant P&ID自动化：依赖DLL嵌入与合并限制咨询

一、将所有依赖DLL嵌入单个EXE的两种常用方案 #

1. 使用Costura.Fody（最简便的方式） #

Costura是Fody的插件，能自动把托管依赖DLL嵌入输出EXE，运行时从资源自动加载。

• 操作步骤：
  • 在NuGet包管理器安装Costura.Fody（选兼容.NET Framework 4.8的最新版本）
  • 项目根目录会生成FodyWeavers.xml，可自定义配置（比如指定要嵌入/排除的DLL、非托管库路径）：

    <Weavers>
      <Costura>
        <IncludeAssemblies>Ingr.SPPID, YourCustomDlls</IncludeAssemblies>
        <ExcludeAssemblies>System.*, Microsoft.*</ExcludeAssemblies>
        <NativeLibs>..\NativeDependencies\</NativeLibs> <!-- 存放非托管DLL的目录 -->
      </Costura>
    </Weavers>
    

  • 直接编译项目，输出的EXE就会包含所有指定的托管依赖。

2. 使用ILRepack（手动控制更强） #

ILRepack是命令行工具，可手动合并多个.NET程序集到单个EXE。

• 操作步骤：
  • 通过NuGet安装ILRepack包，工具会在packages\ILRepack.x.x.x\tools目录下
  • 执行命令行合并：

    ILRepack.exe /target:exe /out:SPPIDAutoTool.exe YourMainExe.exe Ingr.SPPID.dll OtherDependency.dll
    

  • 常用参数说明：
    • /allowDuplicateTypes：允许合并含同名类型的程序集
    • /copyattrs：复制原程序集的版本、版权等属性
    • /keyfile:YourSignKey.snk：若原程序集是强命名的，用此参数重新签名合并后的EXE

二、合并Ingr.SPPID程序集的限制与实际经验 #

核心限制点 #

1. 非托管/COM组件无法嵌入
   Ingr.SPPID依赖的部分DLL是原生非托管代码或COM组件，Costura和ILRepack仅能处理托管.NET程序集，这类非托管文件必须单独携带到部署目录，或提前在目标机器注册COM组件。

2. 强命名冲突风险
   若Ingr.SPPID是强命名程序集，合并后需重新签名，但SPPID的API可能验证原程序集签名，导致运行时抛出SecurityException或程序集加载失败。这种情况建议不要合并Ingr.SPPID，将其放在EXE同目录即可，或用Costura嵌入但保留原强命名（需确保签名密钥可用）。

3. 动态加载逻辑失效
   若Ingr.SPPID内部用Assembly.LoadFrom等方式动态加载依赖，合并后程序集路径改变会导致加载失败。解决方法是修改代码改用Assembly.Load加载嵌入的资源程序集，或在Costura配置中确保动态加载的DLL被正确嵌入映射。

4. 版本绑定严格
   SmartPlant P&ID的API与客户端版本绑定极强，合并后的EXE必须在安装对应版本SPPID客户端的机器上运行，否则会出现InvalidCastException或无法初始化Ingr.SPPID.Application对象。测试时务必在目标环境验证版本兼容性。

5. 权限与环境依赖
   SPPID自动化需要访问注册表和系统资源，合并后的EXE可能需以管理员权限运行，否则会触发权限不足错误。另外，目标机器必须安装SPPID客户端并完成初始化，否则即使合并了DLL也无法调用API。

实际经验参考 #

• 优先用Costura.Fody，配置简单，自动处理资源加载，减少手动出错概率。
• 不要尝试合并非托管DLL，将其放在EXE同目录，或用Costura的NativeLibs配置指定路径，运行时Costura会自动提取到临时目录加载。
• 合并前先单独测试自动化代码确保正常运行，再进行合并，避免合并掩盖原有代码问题。
• 部署前在干净的测试机器（无VS或SPPID开发环境）运行合并后的EXE，验证所有依赖是否正确加载。

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