ASP.NET项目Jenkins构建报错：不允许循环文件引用

我太懂维护多年的ASP.NET老项目时遇到这种本地正常、CI构建炸锅的痛苦了——毕竟老项目的代码里藏着各种历史遗留的小坑。结合你遇到的情况，咱们一步步拆解问题：

为什么本地编译正常，Jenkins构建就报错？ #

VS本地编译默认是增量编译，而且会跳过一些批量编译时才会检测的循环引用问题；而Jenkins用的命令行构建（比如aspnet_compiler）是批量编译模式，会严格检查所有文件的依赖关系，这就把隐藏的循环引用揪出来了。你加batch=false能绕过这个检查，但代价是逐个编译文件，对6年的老项目来说很容易触发内存溢出，毕竟积累的文件数量肯定不少。

排查循环引用的具体步骤 #

你贴的Sorry.aspx和Site.master代码里没看到直接的循环，但错误涉及多个页面（Default.aspx、ManualTransactionInput.aspx），说明问题在其他地方，试试这些方法：

1. 检查App_Code文件夹的类文件 #

老项目最常见的循环引用来源就是App_Code里的类互相依赖：

• 比如ClassA.cs引用了ClassB.cs，而ClassB.cs又引用了ClassA.cs
• 或者通过中间类形成间接循环：ClassA→ClassB→ClassC→ClassA
  批量编译时，ASP.NET会把App_Code里的文件当成一个整体编译，这种循环会直接触发错误。

2. 检查页面后台类与母版页的引用关系 #

看看报错页面（Default.aspx、ManualTransactionInput.aspx）的后台代码，以及Site.master.cs：

• 有没有母版页的后台类（SiteMaster）引用了某个页面的类？比如SiteMaster里实例化了Default类
• 反过来，页面的后台类有没有引用SiteMaster的内部类？
  这种跨页面/母版页的类引用很容易形成隐藏循环。

3. 本地模拟Jenkins的编译命令 #

在本地命令行运行aspnet_compiler，复现Jenkins的构建环境，方便快速排查：

aspnet_compiler -v / -p "你的本地项目路径" "临时输出路径"

如果本地运行也报错，你就能更高效地调试，不用每次都等Jenkins构建。

4. 检查页面的Inherits属性与后台类的匹配 #

老项目可能存在页面Inherits属性和后台类命名空间不匹配的情况，比如页面写的Inherits="Sorry"，但后台类实际在Namespace.Sorry下，这种不匹配也可能被批量编译当成循环引用处理。

解决方法 #

方法一：彻底修复循环引用 #

• 如果是App_Code里的类循环，把循环依赖的类提取到单独的类库项目中，分离依赖关系
• 如果是页面/母版页的类引用循环，重构代码，把公共逻辑抽成独立的工具类，避免互相引用

方法二：绕过循环引用检查但避免内存报错 #

如果暂时没时间重构，试试这些优化batch=false的方式：

• 调整Jenkins服务器的ASP.NET编译进程内存限制：在服务器的machine.config里修改<processModel>节点的memoryLimit属性，提高内存阈值
• 清理Jenkins工作目录的旧构建缓存，避免冗余文件占用内存
• 把项目拆分成更小的模块，分模块编译后再合并

方法三：修改编译顺序（小众但有用） #

在web.config的<compilation>节点里添加<assemblies>，指定优先编译的程序集，打破循环检测的顺序：

<compilation debug="false" batch="true">
  <assemblies>
    <add assembly="System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
    <!-- 添加你的项目依赖程序集，按依赖顺序排列 -->
  </assemblies>
</compilation>

内容的提问来源于stack exchange，提问作者let_the_coding_begin