将所有的aspx.cs文件集中放到同一类库项目下，意味着你揽了ASP.NET预编译的活。也就是说预编译给每个页面生成的代码，你需要自己手写。

先来对比一下正常发布，页面文件内容的变化：

Web.config设置：

Default.aspx:

发布前：

发布后：

Default.aspx.cs:

发布前:

发布后（用.Net Reflector打开bin目录下对应的dll）:

由此可见，预编译做的工作：

1. 为每个页面单独生成一个dll,并在class中为页面上所有服务端空间，声明一个以id命名的控件全局变量。(页面中不用服务端控件，全部是原生的html开发，此可忽略)
2. 解析web.config中的设置。例如:page节点、profile节点。（可以用基类代替page节点设置，可以用全局变量代替profile设置，或者写到appsetting节点下）
3. 编译global.asax成App_global.asax.dll。（不用global.asax,所有的事件方法都是在HttpModule中定义）
4. 编译app_code成app_code.dll。web.config中的Profile节点生成在app_code中的ProfileCommon中。（基本没用过profile，通常使用公共静态属性代替）

    

Demo：

1. 打开vs,新建一个网站。
2. 添加一个类库项目：AspxCsCode,并添加System.Web的引用
3. 为网站添加类库项目的引用。
4. 以上述Default.aspx为例，将Default.aspx.cs剪切到AspCsCode项目中。如下图：
5. 修改Default.aspx.cs代码：

    

6. 修改Default.aspx

    

7. 生成网站。在浏览器中查看default.aspx

   点击登录è

    

    

总结

优点：

1. aspx与cs分离了。aspx完全可以交给前端工程师，Cs交给后端工程师，分工更明确，开发效率更高。
2. 支持单元测试。以往开发页面，想测试aspx.cs中某个方法，只能浏览页面。如果放到类库项目下，单元测试将变得很方便
3. 网站发布时很快。编译类库项目是相当快的。如果没用到Global.asax和App_Code的话，基本上都不需要发布了。

缺点：

1. 揽了ASP.NET预编译的活。如果项目中不用服务端控件，这个基本可以忽略
2. 发布的时候，有覆盖他人页面的风险。跟团队成员讨论，部分人觉得，把所有页面的cs文件放到一个类库项目中，

   当我修改了a.aspx.cs,b.aspx.cs也被别人修改时或者还没有被签入，我没有获取最新版本，然后就把类库编译成的dll，更新到服务器上从

   而会出现问题，更偏好Asp.net预编译生成的一个页面对应一个dll的方式，只发布自己改的文件，将影响面积降到最低。

   个人觉得这个缺点的理由不够充分，既然要发布，那就必须保证你编译的所有代码版本不应该比服务器上的版本低，

   如果这个保证不了，那怎么能保证页面引用的其他dll是最新的呢，而且如果照上述逻辑，

   asp.net mvc岂不是也有这种情况？给每个cs都单独生成一个dll岂不更好？

   故而认为，不管哪种方式都有覆盖他人代码的风险，只是这种方式风险稍微大些。