我之前也碰到过一模一样的问题，核心原因其实很简单：Dotfuscator在混淆过程中会对DLL的字节码做大量修改（比如重命名类/方法、控制流混淆、字符串加密等），如果先签名再混淆，混淆后的文件哈希值会和签名时的哈希完全不匹配，自然签名就失效了；而你把DLL移出混淆配置时，文件没被修改，签名自然能正常完成。

下面是几个经过验证的解决思路：

1. 调整流程：先混淆，后签名 #

这是最直接有效的方案，确保签名操作在混淆完全结束后执行：

• Visual Studio集成场景：在Dotfuscator的配置界面里，先关闭内置的签名选项（如果开启了的话），然后修改项目的构建流程。可以通过MSBuild脚本控制顺序，确保<Dotfuscate>任务在<SignFile>任务之前运行；或者在项目属性的“生成事件”里，把签名命令放在Dotfuscator执行命令之后。
• 命令行场景：先执行混淆命令，再用signtool签名混淆后的文件，示例命令：

  # 第一步：执行Dotfuscator混淆
  dotfuscator.exe your_obfuscation_config.xml
  # 第二步：对混淆后的DLL进行数字签名
  signtool sign /f your_certificate.pfx /p your_cert_password "bin/Release/Obfuscated/your.dll"
  

2. 用Dotfuscator内置的签名功能自动完成 #

Dotfuscator本身支持在混淆流程结束后自动签名，这样不用手动调整顺序，配置起来也很方便：

• 打开你的Dotfuscator配置XML文件，添加或修改<Signing>节点，配置证书信息：

  <Signing>
    <!-- 引用PFX格式的证书文件 -->
    <Certificate FilePath="path/to/your_cert.pfx" Password="your_cert_password" />
    <!-- 可选：添加时间戳，避免证书过期后签名失效 -->
    <Timestamp Url="http://timestamp.digicert.com" />
  </Signing>
  

• 确保配置里的<Input>节点包含需要混淆的DLL，Dotfuscator会自动在混淆、优化等操作完成后执行签名。如果你的证书存在本地证书库，也可以通过StoreName和StoreLocation来配置，不用指定PFX文件。

3. 排查可能冲突的混淆选项 #

有些特殊的混淆设置可能会干扰签名，建议逐一排查：

• 强名称签名设置：如果你的DLL是强名称签名的，要在Dotfuscator的配置里找到「Strong Name」选项，设置为「Preserve」或者「Re-sign」，避免混淆过程中破坏强名称的有效性，导致后续数字签名冲突。
• 加密类选项：比如字符串加密、控制流混淆这类深度修改字节码的功能，偶尔会导致签名工具无法识别文件结构。可以暂时关闭这些选项，测试签名是否正常，逐步定位是哪个功能引发的问题。

4. 验证签名结果 #

每次调整后，一定要验证签名是否有效，用signtool执行验证命令：

signtool verify /pa "path/to/your_obfuscated.dll"

如果验证失败，根据错误提示排查：比如“哈希不匹配”说明混淆后没重新签名；“证书无效”则是证书配置或权限的问题。

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