ConfuserEx 已停止维护，不兼容 .NET Core/.NET 5+，混淆后易触发 BadImageFormatException 或崩溃；其字符串和资源几乎不混淆，无法真正保护核心逻辑，应停用并改用 publish + ILRepack 等更稳定方案。
ConfuserEx 不再维护，混淆 C# 程序风险极高
ConfuserEx 自 2017 年起已停止更新，其最新版（1.0.0）仅支持 .NET Framework 4.6 以下、且不兼容 .NET Core / .NET 5+。当前绝大多数项目（尤其是使用 Microsoft.NET.Sdk SDK 的新项目）在构建后会生成含嵌入调试符号、IL 元数据优化、甚至 ReadyToRun 代码的输出，ConfuserEx 无法正确解析这些结构，运行时大概率触发 BadImageFormatException 或 InvalidProgramException。
它对泛型实例化、动态方法（DynamicMethod）、Expression 树、反射调用（如 Assembly.Load、Type.GetMethod）等场景也缺乏处理能力，混淆后程序崩溃是常态而非例外。
为什么 confuser.exe 运行后没报错但程序打不开
这是最典型的 ConfuserEx 失败表现：配置看似成功，日志显示 “Protection applied”，但双击 exe 直接无响应或闪退。根本原因在于混淆器跳过了关键校验：
- 未检查目标程序是否启用了
NGEN或ReadyToRun（这类二进制无法被 ConfuserEx 处理） - 未验证
AssemblyResolve事件中加载的程序集是否也被混淆（漏混淆会导致FileNotFoundException） - 混淆后的
mscorlib引用仍指向原始强名称，而 .NET 运行时拒绝加载签名被破坏的框架程序集
解决方式不是调参数，而是停用 ConfuserEx —— 改用 dotnet publish 的 --self-contained false + ILRepack 合并 + 手动剥离 PDB 和 DebuggableAttribute，效果更稳定。
替代方案：用 dotnet-trace + ildasm 快速验证混淆结果
如果你必须评估某混淆工具的效果（比如试用 ConfuserEx 的 fork 版本），不要依赖“文件变小”或“反编译器打不开”这种假象。真实验证步骤如下：
- 用
dotnet-trace collect --process-id [pid]捕获运行时方法调用栈，确认敏感逻辑（如 license 校验）是否仍以明文符号出现 - 用
ildasm YourApp.exe /output=disasm.il导出 IL，搜索关键字符串（如"trial expired"、"ValidateKey"），ConfuserEx 默认只 rename 类型/方法名，字符串和资源几乎不碰 - 检查
Assembly.GetExecutingAssembly().GetManifestResourceNames()输出，混淆后资源名若未重命名，攻击者可直接提取EmbeddedResource
你会发现，即使 ConfuserEx 显示成功，90% 的业务逻辑仍能被静态分析定位 —— 它解决的只是“最表层的反编译门槛”，不是真正的保护。
混淆不是安全手段，而是增加逆向成本的权衡
真正需要保护的核心（如密钥、算法逻辑）不该放在客户端。混淆不能替代服务端校验、硬件绑定或白盒加密。如果你的程序靠“不让别人看到 DecryptLicense 方法名”来防破解，那混淆再强也没用 —— 攻击者会用 dnSpy 下断点，看寄存器值，而不是读源码。
现代 .NET 生态中，值得投入精力的是：dotnet publish -r win-x64 --self-contained false 减少依赖体积、用 StrongNameSigner 重签名防止篡改、配合 Windows AppContainer 或 macOS Hardened Runtime 限制进程行为。混淆该省就省。
