多程序集项目里经常会遇到Agile.NET程序集保护怎么执行，以及Agile.NET程序集保护后引用丢失怎么办的问题，单个exe的保护做起来还算省事，但是真实的软件项目里往往会把主程序、业务DLL、公共类库、插件库、第三方组件、资源文件和配置文件都包含进来，只要其中的某一个程序集被开发人员执行了重命名、加密或者移动，并且没有把相关处理同步好，系统就很容易把引用弄丢，从而让类型或者方法找不到了，最后导致启动失败。

　　一、Agile.NET程序集保护怎么执行

　　开发人员在使用Agile.NET做程序集保护的时候，代码里的类名和方法名不只是被改变了，连带着托管资源、用户字符串、方法实现、系统调用还有库调用等很多内容都会被该工具处理，而且哪些内容需要被保护，哪些内容需要被保留，都是可以由用户去控制的；

　　所以开发人员在执行操作前，必须先把程序集之间的调用关系给理清楚，千万不能直接把整个发布出来的文件夹拖进工具里就去点保护。

　　1、先确认程序集范围

　　开发人员首先要把自研的程序集和第三方的程序集给区分开，一般来说，主程序exe、自己写的业务dll、公共工具dll都是可以被纳入到保护范围里的；但是像第三方控件、数据库驱动、硬件SDK、授权组件还有系统依赖库这些，大家不建议随便去把它们混淆，因为第三方库往往已经被别人编译完了，里面可能还把签名、反射和授权校验给包含进去了，如果去强行保护，引用关系反而容易被破坏掉。

　　2、准备干净的Release包

　　在保护被执行之前，开发人员要先用Release模式把项目完整地编译一遍，并且还要把这个没保护的版本给运行一下，需要去确认启动、登录、主界面、数据库连接、文件读写还有导入导出都是正常的；这个没有被动过的版本要被单独备份起来，后面如果混淆出问题了，可以直接被拿来做对比。

　　3、创建Agile.NET保护项目

　　当新的Agile.NET项目被创建好了之后，需要被保护的程序集就要被加入到这个项目里，根据Agile.NET说明书里的流程，首先要把项目建好，然后要把软件包含的程序集选上，接着要把保护操作配置好，最后把工具运行起来就能把受保护的程序集给生成出来；

　　在实际操作的时候，新目录（比如【Protected】或【Release_Protected】）建议被用来做输出路径，不要去把原本的Release目录给覆盖了。

　　4、按项目关系选择保护方式

　　如果项目里只有单个exe，名称混淆、字符串加密还有控制流保护等基础项可以先被开启；但如果是好几个自己写的dll在互相调用，跨程序集引用的问题就要被注意到了，Agile.NET里的Cross Assembly Obfuscation功能可以把多个互相引用的程序集之间的外部引用做统一的重命名，这样就能避免A程序集里的类型被改名后，B程序集还在用老名字去调用的情况。

　　二、Agile.NET程序集保护后引用丢失怎么办

　　当程序集保护被弄完之后，如果引用丢了，程序在启动时往往会把错报出来，或者是在某个功能打开的时候，FileNotFoundException、TypeLoadException、MissingMethodException、ReflectionTypeLoadException等报错会被抛出来；这时候开发人员不要急着把Agile.NET重新安装，先要把问题判断一下，看看是因为程序集文件少了、版本不对，还是因为混淆把名字改了才导致调用不成功。

　　1、先检查文件有没有真的缺失

　　在被保护后的输出目录里，主程序exe、业务dll、配置文件、资源文件还有native dll是不是都在，这件事需要被开发人员确认好；很多时候引用并不是被混淆给弄坏的，而是打包的时候某个dll被漏掉没复制，尤其是数据库驱动、图像库、打印组件、硬件SDK这些依赖，它们在Visual Studio本地能跑，不代表发布目录里就一定齐全。

　　2、检查版本和目标框架是否一致

　　如果原本的项目用的是.NET Framework 4.x，那么不同框架版本下的dll就不要被混在一起；如果项目是.NET Core或者.NET 5/6/7，那么运行时文件以及.deps.json、.runtimeconfig.json的完整性也要被确认好，如果保护做完后只有exe和dll被复制了，运行时配置文件没被复制，启动的时候也会因为找不到依赖而报错。

　　3、检查是否只保护了部分自研程序集

　　在有很多程序集的项目里，“只把A保护了，没有把B同步保护”是最容易让人犯错的地方；比如A.dll里的类名被改掉了，但是旧的类名还在被B.dll引用，运行的时候自然就找不到了；这种情况有两个解决办法：要么把互相引用的自研程序集都塞到同一个Agile.NET项目里去进行统一保护，要么把需要被其他程序集调用的公开类型设置成排除，不让它们被改名。

　　4、检查公开接口是否被重命名

　　如果某个dll需要被提供给外部的系统去调用，那么里面的公开类、公开方法和公开属性就不能被随便乱改；比如客户在做二次开发的时候需要把你的SDK调起来，或者插件需要通过固定的接口把你的dll加载上去，一旦名字被改了，引用丢失的错就会被外部程序报出来；这时候的做法是把这些API类放到【Exclude】规则里，让命名空间、类名、方法名和属性名都被保留下来。

　　三、保护程序集时怎样减少引用问题

　　程序集保护并不是做得越多就越好，每个dll也不是都要用一样的强度去弄；比较稳妥的做法是把程序集按照用途分层保护，核心的算法和授权逻辑要被保护得更深一些，对外接口和框架入口则要被保留得更稳一些。

　　1、核心业务dll重点保护

　　核心算法、授权校验、业务规则还有关键的计算逻辑，名称混淆、控制流保护和字符串加密这些功能都可以被开启，甚至更强的保护在必要时也能被加上；在这里，把反编译分析的难度给提高上去才是大家的目的。

　　2、接口层和模型层适当保留

　　Controller、DTO、ViewModel、实体模型、插件接口还有SDK公开类，它们不一定适合被强行重命名；因为它们在很多时候把“对接”和“映射”的作用给承担起来了，如果被过度混淆，运行反而容易被影响到。

　　3、第三方依赖尽量不动

　　第三方dll一般只要随着包一起发布就行了，它们不参与Agile.NET的保护；除非开发人员非常确定它能被处理，并且把所有的调用场景都测试过了，否则它不要被拿来和自研程序集一起混淆。

总结

　　关于Agile.NET程序集保护怎么执行，重点就是先把程序集的关系理清楚，再把自研的exe和dll放到同一个保护流程里，并把名称混淆、控制流、字符串加密等选项按需开启；而对于Agile.NET程序集保护后引用丢失怎么办，大家不能光盯着工具的设置看，而是要从文件缺失、版本不对、跨程序集重命名、公开接口还有反射配置这几条线去排查；只要排除规则被做得足够细，保护范围被分得足够清，多程序集的项目也是能把保护和发布工作比较稳定地应付过去的。