在对多项目工程进行混淆保护的时候，最怕碰到的情况就是只保护了主程序，别的程序部件却还抓着原来的引用关系不放。Agile.NET多项目工程到底该怎么统一保护，它的引用关系又要怎么检查，大家可以从程序组件的清单、保护顺序、公开成员，还有保护后的运行验证这四个方面来着手处理。按照Agile.NET文档的说明，在新建了保护工程以后，应当把软件所牵涉到的各个程序集都加进项目里来，然后再根据实际需要去配置保护的方式，最后把经过保护的程序集重新生成出来。

　　一、Agile.NET多项目工程如何统一保护

　　对于多项目工程，不能把那些DLL文件一个一个地随手拾掇一下就了事，因为主程序、业务库、公共组件和插件之间是存在引用关系的，一旦保护配置就这么分散着去设，很容易就会发生某个DLL的名称已经被改掉了、调用端那一头却没有同步更改过来的情形。

　　1、先整理程序集清单

　　先把exe、业务相关的DLL、公共的DLL、插件接口，还有本地的依赖这些，一个一个列清楚，并且要标明它们当中谁引用了谁。进到Agile.NET里面新建一个工程以后，就把这次发布要用到的程序组件全都统一地加到项目里头来，就算有些组件眼下还不打算做深度的保护，也最好别轻易地就把它们给漏掉了。

　　2、统一设置重命名范围

　　进到软件的【Renaming】页面，把需要执行符号重命名的那些程序组件给勾上，然后再去选一套合适的命名方案。官方文档里头有过说明，Cross Assembly Obfuscation这个功能会把跨越程序组件的引用关系一并给统一修改掉；当你把这个功能启用起来的时候，软件所涉及的所有程序组件都得搁到同一个工程里面，哪怕是其中有一部分本来不准备保护的，也一样不能例外。

　　3、针对不同程序集采用不同保护强度

　　主程序和核心算法库这一类，可以让它们用上比较完整的保护措施；而反射调用次数比较多的、需要开放给外部调用的，或者是要支持插件扩展的那些公共接口，在对它们进行重命名处理的时候就要小心着些。不要光图个统一就把一模一样的保护强度往所有DLL身上套，保护得过了头，有时候反而会影响程序正常地跑起来。

　　4、保留工程文件和映射文件

　　每一次发布，都要把Agile.NET的工程文件、输进去的程序组件、输出来的程序组件，还有那份map映射文件，都好好地归档存起来。如果后续的补丁版本只是替换了其中的一部分DLL，那么就可以把旧版本留下来的映射文件再拿过来用，这样新版本仍然可以顺着原有的命名关系走下去。

　　二、Agile.NET多项目引用关系该怎么检查

　　引用关系的检查，不能仅仅去看项目在编译的时候过不过得去，混淆之前能够顺顺利利编译的，混淆完了以后照样有可能在启动、反射调用、序列化，或者是插件加载这些环节上突然就报错。

　　1、检查程序集依赖

　　在着手保护之前，先把主程序和各个DLL之间的依赖关系梳理一遍，确保工程里面没有漏下任何一个内部的程序组件，尤其是那些公共模型库、接口库，还有插件目录，它们平时看上去不显山露水的，可程序一旦运行起来，却经常都是被动态加载进去的。

　　2、检查公开成员

　　在Agile.NET默认的设定底下，被选中的程序组件里头的公开成员是不会被重命名的，因为指不定哪些还没有被纳入改名流程的程序组件正在引用着它们。等到跨程序集混淆的功能被打开以后，这些公开成员倒也可以给隐藏起来，不过这里头有个前提，就是相关的调用端全都已经被放进了同一个工程里面。

　　3、检查反射和序列化

　　凡是靠着字符串去调用类名、方法名或者属性名的那种代码，都要当成重点对象来抽查。官方文档也讲到了，重命名过后反射调用很有可能就不灵了；对于那些工具自己没能自动识别出来的依赖关系，可以由人工手动地去添加一些排除项，让它们不被改名。

　　4、检查插件和外部接口

　　倘若某个DLL文件会被第三方的程序所调用，又或者程序本身会照着文件名、类名去动态地加载插件，那就不应当把全部的公开成员直接就给隐藏掉。可以先让接口层的名称原样保留，只对着内部的实现部分去做保护。

　　三、Agile.NET多项目保护后怎么验证

　　保护工作全都做完以后，别只在启动首页上瞅一眼就算完事了，多项目工程里的问题往往是藏在业务深处的，一定得照着真实发布的那条路径去完整地过一遍才行。

　　1、换成完整输出包测试

　　测试的时候，只应当使用那些经过了混淆处理的exe和DLL，可不要把原始的、没保护过的程序组件给混了进去。程序的启动、登录、配置读取、插件加载、导入导出，还有异常日志这些个功能，全部都要覆盖到。

　　2、逐项验证关键调用

　　要把跨DLL的调用、反射、序列化、依赖注入，以及外部的接口作为重点来测试。有些功能得进到了特定的页面以后，才会去加载对应的DLL，光凭首页能正常打开这一点，可证明不了保护之后的结果就是靠得住的。

　　3、核对发布目录

　　在发布之前，先去检查一下输出的目录，看里头有没有旧的DLL文件剩在那一块，更不能出现原始DLL和混淆过后的DLL混着放在一起的情况。版本号、文件的时间，还有map文件归档下来的记录，这些信息都得能够对得上号才行。

　　总结

　　多项目保护做得稳不稳当，主要就是看程序组件有没有都搁在同一个保护工程里头，还有它们之间的引用关系是不是在动手之前就给摸清楚了。Agile.NET多项目工程如何统一保护，Agile.NET多项目引用关系该怎么检查，处理起来的顺序可以像这样去排：先把程序组件的清单列出来，再把它们统一加到工程当中，接着按照引用关系设置好重命名的范围，随后把映射文件保留下来，最后拿完整的输出包去做验证。这么一来，不但核心代码能够被保护好，上线以后出现调用异常的风险，也就可以跟着降下来不少了。