很多人碰到Agile.NET运行时报错，第一反应都是去找某个固定DLL，但这个问题如果不先分清保护类型，很容易越找越乱。按SecureTeam当前官方文档，真正明确会额外引入原生运行时组件的是Code Encryption，也就是代码加密；它会增加需要随软件一起分发的native component，并同时提供x86和x64两个版本。更关键的是，这个运行时组件默认会被直接嵌进受保护程序集，所以不少项目实际上根本看不到单独的运行时文件。也就是说，先判断你有没有启用代码加密，再判断是否关闭了运行时嵌入，比一上来就在目录里盲找更有效。

　　一、Agile.NET运行时组件在哪里

　　要找Agile.NET的运行时组件，先别把所有保护功能都混成一类。官方文档写得很明确，Code Encryption会增加native runtime component，而Symbol Renaming、String Obfuscation、Control Flow这一类页面本身并没有同样的单独运行时说明，所以“运行时组件在哪里”首先要看你到底启用了哪种保护。

　　1、如果启用了代码加密，运行时组件有两种存在方式

　　第一种是默认方式，也就是被直接嵌入到加密后的程序集里。官方说明里明确写到，默认情况下Agile.NET会把运行时组件直接embed到encrypted assembly中，这种情况下部署包里不一定能看到独立文件。第二种是手动关闭嵌入，也就是勾选【Disable runtime embedding】后，把运行时组件作为单独文件随软件一起发布。

　　2、如果你现在根本看不到单独文件，不一定是少了

　　很多项目找不到运行时组件，并不是因为丢了，而是因为它本来就被嵌进了受保护程序集。官方在Native Runtime Components说明里已经把这一点写得很清楚，所以“目录里没有单独runtime文件”本身不能直接等同于“运行时缺失”。

　　3、如果关闭了嵌入，就去受保护输出和发布目录找

　　一旦关闭运行时嵌入，运行时组件就需要跟着软件一起部署。结合.NET官方发布文档，应用发布后的依赖和相关文件会进入publish输出目录，默认是项目下的bin目录分支里的publish文件夹，所以这时优先检查受保护程序集的输出目录和最终publish目录，而不是只看源码目录。

　　4、复制保护和授权相关文件不要混着找

　　如果你用到了Agile.NET的Licensing API，官方API文档明确给出了AgileDotNet.Licensing.dll这个程序集名称；同时，许可证创建侧还会用到AgileDotNet.Licensing.PrivateKey.bin，而且这个文件位于Agile.NET应用程序路径。这个位置是给Agile.NET工具侧和授权生成侧看的，不应和客户机运行时目录混为一谈。

　　二、Agile.NET运行时缺失怎么定位

　　定位“运行时缺失”，不要只看报错字面，而要先确认它到底是加密运行时没带上，还是发布过程把native dependency漏掉了。按照官方口径，最有效的排查顺序其实很固定。

　　1、先看工程里有没有启用Code Encryption

　　官方文档明确只有Code Encryption页面直接说明会增加native runtime component。如果项目只做了重命名、字符串混淆或控制流混淆，那运行时缺失就不一定是主因，继续沿着runtime文件去找，方向本身可能就是错的。

　　2、再查【Disable runtime embedding】是不是被打开了

　　这是最关键的一步。因为默认状态下运行时被嵌入程序集，不需要额外把运行时组件手工塞进部署包；只有你主动关闭嵌入时，才需要把对应组件单独发布。也就是说，缺失问题往往不是“文件为什么不在”，而是“本项目到底是不是要求它单独在”。

　　3、然后核对目标平台是不是对上了

　　官方说明里提到，Agile.NET会同时提供x86和x64两个版本的运行时组件。微软发布文档也强调，带有native dependencies的.NET应用最好按明确的目标平台发布，也就是使用对应RID，把平台相关依赖复制到publish folder。实际排查时，如果你的程序按win x64发布，却只带了错误架构的组件，表现出来也会像运行时缺失。

　　4、最后去publish目录核对依赖是否真的被带出

　　.NET官方文档明确写到，publish的结果会包含executable或binary、dependencies以及related files；如果应用有native dependencies，按具体平台发布时这些依赖应被复制到publish folder。所以上线前最稳的做法不是靠安装包猜，而是直接检查最终publish目录，看受保护主程序、依赖文件和平台相关文件是不是都在同一套交付物里。

　　三、Agile.NET部署检查怎么固化

　　同样的缺失问题之所以反复出现，通常不是工具本身不稳定，而是团队每次发布时都没有把保护配置和交付检查固化下来。只要把下面这层口径先定住，后面排查会省很多时间。

　　1、先固定保护组合

　　如果这一版需要Code Encryption，就把它作为单独的发布条件写进流程；如果这一版只做普通混淆，不做代码加密，就不要让团队默认去找运行时组件。这样能先把问题范围缩小。

　　2、再固定嵌入策略

　　团队最好明确写清楚，是始终使用默认的runtime embedding，还是某些项目为了部署方式要统一关闭嵌入。因为这一步直接决定运行时组件是藏在程序集里，还是必须以独立文件形式进入交付目录。

　　3、发布时固定按目标平台出包

　　微软文档已经说明，针对native dependencies的项目，最好按具体平台发布，并让相关依赖进入publish folder。对Agile.NET这类存在x86和x64区分的运行时场景，按平台出包比做一份模糊的通用包更稳。

　　4、把工具侧文件和客户侧文件分开

　　AgileDotNet.Licensing.dll、许可证API相关程序集，以及AgileDotNet.Licensing.PrivateKey.bin这种工具侧或授权侧文件，不要和客户机运行时交付物混放。前者服务于授权生成或许可逻辑，后者才是最终发布目录里真正要跟应用一起跑的部分。边界一旦不清，缺失问题和误打包问题就会反复出现。

　　总结

　　Agile.NET运行时组件在哪里，先看是不是启用了Code Encryption，再看运行时是不是被默认嵌入；如果关闭了嵌入，就去受保护输出目录和最终publish目录找，而不是在工程根目录盲搜。Agile.NET运行时缺失怎么定位，最有效的顺序就是先查加密开关，再查【Disable runtime embedding】，再核对x86和x64平台，最后检查publish结果里依赖是否齐全。把这几步固定下来，大多数“运行时缺失”问题都能很快收口。