最近由于项目布署需要在解决方案里面添加了WebDeploymentProject, 但是在生成这个工程时总是报循环引用，查阅相关资料提示关闭web.config里面的批处理开关<compilation batch="true" />但好象还是不管用. 据“官方”的说法是asp.net将不同的文件夹里面的控件和页面编译到一个程序集中产生的问题。后来实在没办法，只好将所有的用户控件全部搬到一个目录里面去，改了两天两夜才改完, 但是结果仍然不能满意。

无奈之中打开了几个用户控件忽然发现，控件的名称居然跟后台的类名称不能对应起来。这样问题就比较明显了，我们的开发人员在编写控件后对控件进行了改名,但是VS里面的操作默认只将页面名称和后台代码的文件名称改过来了，里面的类名称并没能改过了，这样的话以后假如再有这样的一个控件，并且名称正好与原来的那个类名相同的话就会出问题了，出现了两个类名称相同的冲突，我们现在确实存在这样的情况,但是这个并不能在生成网站的时候被发现。但是生成WebDeploymentProject的时候是会被检测出来的，但是为什么没有具体的报错信息出来呢，只是简单的提示一个"不允许循环引用"的错误，一度也把我搞得很困惑，后台在配置管理器里面发现默的编译输出信息是被设为“最小’模式，这样在输出控制台上看到的信息就非常有限，只要把这个输出模式改为“详细”或者是“诊断”模式就可以发现问题，它会报告某两个控件的继承类名称出现了重复,这样就可以轻松定位到故障点了。

总的说来这次的问题还是由于编码的不规范造成的，基于此有必要强调一些基本的编码规范.
1. 控件名称要与类名对应，在修改控件名称时类名称也要一并修改.
2. 给控件和页面后台类加上命名空间减少出错机会.
3. 拖用户控件的时候不充许使用uc1,uc2这样的名字空间，使用统一的名称.4. 当两个控件需要重用后台类代码时需要将后台类独立出来，不使用CodeFile的属性指名，使用Inherits来指定继承的类名称. 如果不这样也会出问题.

另外要说明的是在使用WebDeploymentProject的时候它对代码的要求比较严格，凡是存在警告的编译错误的代码都不能生成成功。使用WebDeploymentProject的好处也是很明显的，它可以直接将页面预编译存储下来，这样就不需要Asp.net运行环境在程序第一次运行的时候进行预编译，启动速度会提高不少.