程序集原本带有强名称，经过Agile.NET混淆、加密或合并后，却出现“强名称验证失败”，这种情况并不少见。保护过程会改写程序集内容，原签名自然无法继续对应新的文件。

　　处理“Agile.NET强名称签名怎么保留Agile.NET保护后程序集签名失效如何修复”，要把重新签名放进保护流程。原来的私钥文件也得保留好，临时换一把新密钥，程序集身份会跟着变化。

　　一、Agile.NET强名称签名怎么保留

　　Agile.NET支持在保护完成后重新签名。项目本身已经使用强名称时，应选择最初编译时使用的同一份密钥文件，软件会在修改程序集后重新生成签名。

　　1、确认原程序集签名状态

　　①打开Visual Studio开发者命令提示符。

　　②验证原程序集：

　　sn-vf MyApp.dll

　　③查看原公钥标记：

　　sn-T MyApp.dll

　　④记录输出结果。

　　sn-vf会强制验证强名称签名，sn-T用于显示程序集的公钥标记。后面保护完成后再查一次，很快就能看出签名有没有保住。

　　2、在Agile.NET项目中选择原密钥

　　①打开Agile.NET，新建或载入保护项目。

　　②添加需要保护的EXE和DLL。

　　③设置独立的输出目录。

　　④找到强名称密钥或签名文件设置。

　　⑤选择原项目使用的.snk密钥。

　　⑥执行保护并生成新程序集。

　　这里一定要用原密钥。随便新建一个.snk虽然也能签名，但公钥标记会变，其他程序集仍按旧身份引用它，运行时就可能加载失败。

　　Agile.NET还建议把软件包含的程序集一起加入项目，即使部分DLL不做混淆，也可以由工具复制到统一输出目录。这样不容易把保护后的主程序和旧版依赖混在一起。

　　3、命令行构建时启用重新签名

　　自动化构建可以使用Agile.NET命令行参数：

　　/Resign:

　　该参数用于使用指定签名文件，重新签署强名称或延迟签名的程序集。

　　流水线里的顺序可以固定为：

　　①编译Release程序集。

　　②将文件复制到临时保护目录。

　　③执行Agile.NET保护。

　　④使用原密钥重新签名。

　　⑤验证签名后再发布。

　　别直接在编译输出目录里覆盖原DLL。保护失败时，原始文件也被替换了，想对比都找不到。

　　4、保护完成后重新验证

　　①对输出程序集执行：

　　sn-vf SecuredMyApp.dll

　　②再查看公钥标记：

　　sn-T SecuredMyApp.dll

　　③与原程序集的公钥标记对比。

　　④启动程序并测试依赖加载。

　　验证成功、公钥标记也一致，说明程序集仍保持原来的强名称身份。光看文件能启动还不够，有些签名问题要到特定DLL被加载时才会暴露。

　　二、Agile.NET保护后程序集签名失效如何修复

　　签名失效后，先看保护项目有没有配置密钥，再看后面是否还有工具修改过程序集。签完名以后又改文件，签名照样会失效。

　　1、保护时没有提供密钥

　　最直接的处理方式，是重新打开Agile.NET项目，加入原始密钥后再生成一次。

　　①删除本次错误输出。

　　②使用未保护的原始程序集重新开始。

　　③配置原.snk密钥。

　　④再次执行保护。

　　⑤用sn-vf验证结果。

　　不建议拿已经保护过的文件反复套保护。处理层数多了以后，运行异常会更难判断，还是从干净的Release文件重做更稳。

　　2、保护后又被其他工具修改

　　资源写入、程序集补丁、安装包处理和其他后处理工具，都可能再次改动程序集。Microsoft也说明，强名称程序集经过后处理后，原签名可能失效，需要重新签名；另一种做法是先延迟签名，所有处理完成后再补齐完整签名。

　　构建顺序可以调整为：

　　①完成混淆、合并和资源修改。

　　②确认文件不会再被改写。

　　③执行最终强名称签名。

　　④再做签名验证。

　　⑤最后打包发布。

　　简单说，强名称签名尽量放在最后一次程序集改写之后。后面又动了DLL，就得再签一次。

　　3、程序集采用了延迟签名

　　延迟签名的程序集只写入公钥，并预留签名空间，最终还要使用包含私钥的密钥对完成签名。Microsoft的Sn.exe支持使用-R重新签署已签名或延迟签名的程序集。

　　可以执行：

　　sn-R SecuredMyApp.dll OriginalKey.snk

　　随后再验证：

　　sn-vf SecuredMyApp.dll

　　开发环境为了调试跳过验证，只能算临时处理。到了正式发布阶段，仍要完成完整签名，别把“本机能跑”当成修好了。

　　4、原来的私钥文件已经丢失

　　只有公钥文件时，无法重新生成与原程序集相同的完整签名。强名称签名需要公钥和私钥组成的密钥对。

　　这种情况通常只能找回原密钥备份，或者更换新密钥并重新构建所有相关程序集。

　　换新密钥后，公钥标记也会变化。引用旧程序集身份的项目、插件和配置都要跟着更新，工作量可能不小，所以密钥文件真不能随手丢。

　　5、合并程序集后签名丢失

　　使用Agile.NET合并多个程序集时，第一项程序集会作为主程序集。主程序集带有强名称，并且项目提供了签名文件时，合并后的目标程序集会使用该密钥重新签名。

　　合并后出错，可以检查：

　　1、主程序集是否选对。

　　2、签名文件是否已经配置。

　　3、依赖DLL是否仍引用旧程序集。

　　4、输出目录中是否混入旧文件。

　　别一边用合并后的单文件，一边又把旧DLL全部复制到发布目录。运行时加载到哪一份，很容易说不清。

　　三、怎样让程序集保护和签名流程更稳定

　　签名问题反复出现，多半是构建步骤没有固定下来。人工保护一次、手工复制一次，少一个文件或选错一个密钥都很正常。

　　1、把保护和签名写入构建流程

　　建议固定“编译、保护、重新签名、验证、打包”的顺序。任意一步失败，就停止发布，不要继续生成安装包。

　　原始程序集、保护后程序集和最终发布文件也要分目录保存。文件名一样没关系，目录必须分清。

　　2、统一检查所有程序集

　　主程序签名正常，某个依赖DLL签名失败，程序仍可能在启动或调用功能时出错。

　　可以对发布目录中的EXE和DLL逐个执行强名称验证。数量多时写成脚本，一次性跑完，比人工点开检查靠谱。

　　3、不要混淆强名称和代码签名

　　Microsoft明确说明，强名称主要提供程序集唯一身份，不应被当成安全信任机制。它和使用证书完成的代码签名不是一回事。

　　项目同时使用强名称和数字证书时，一般先完成程序集保护与强名称签名，再进行最终代码签名。这样后面的保护步骤不会把已经生成的文件签名再次破坏。

　　总结

　　“Agile.NET强名称签名怎么保留Agile.NET保护后程序集签名失效如何修复”关系到程序集身份、依赖加载和发布流程是否稳定。原密钥妥善保存，保护与签名顺序固定，再配合发布前验证，能减少很多运行阶段才暴露的问题。希望本文对大家处理Agile.NET程序集签名问题有所帮助。