下面的内容要从新版Recruiting上线时出现的问题说起，
记得当时我们遵循以往发布VS2003项目的方式将前台页面以及所有静态文件，加上程序集DLL发布到服务器上。
结果出现系统错误，大概意思是缺少***.cs文件。在开发和测试环境试过，也出现这种情况。
当我们将**.cs文件也更新上线时，系统就可以正常运行了。
所以当时的结论是VS2005的WEB项目发布需要带后台文件，也没有深究。
然而最近我又尝试将**.cs文件拿走，访问系统居然完全正常，无论怎么重启IIS都是正常的。同样的操作隔段时间居然两种不同的结果--------------奇怪！！~ 这点希望有高人指点。
其实网上大多数介绍的VS2005编译方式有变化的文章指的是Web Site项目，而Web Application项目基本和VS2003一样。（本人猜测文章撰写的时候微软的VS SP1还没有出来吧）
所以本篇文章的结论是在VS2005种使用Web Application项目在编译方式上和在VS2003中基本一致。
参考微软的介绍:http://msdn2.microsoft.com/en-us/asp.net/aa336618.aspx
The Visual Studio 2005 Web Application Project model uses the same project, build and compilation semantics as the Visual Studio .NET 2003 web project model.
简单介绍Web Site新的代码编译功能
而Web Site是默认在运行时动态编译的，但都需要发布源代码，优点主要是允许运行时同时对 Web 窗体页和 Codebehind 类进行动态编译，无需再为一次更改而重新编译整个项目。
ASP.NET Web 窗体的优势之一就是增加动态编译后，您可以很轻松地更改 .aspx 页，保存更改时页面将动态更新，而不需要重新编译（只要不使用代码隐藏）。但动态编译并不是
对每个应用程序都适合，而且第一次访问某个应用程序时，动态编译会导致初始性能降低。另外，可能很多时候您确实想要部署一个不含源代码的应用程序。
如果您遇到上述情况，您会高兴地了解到 ASP.NET Whidbey 具有支持预编译 Web 站点的功能。ASP.NET Whidbey 支持两种预编译模式：就地预编译和部署预编译。
Web Application Projects和Web Site Projects的比较
下面是我从网上摘下来的两种项目之间的比较，基本上Web Application项目可以说是微软用来为VS2003过渡的。
你该选择哪种WEB编程模型
|
Option or Task
|
Web Application Projects
|
Web Site Projects
|
|
你有一个大型的Visual Studio .NET 2003 Web应用需要迁移到VS2005。
|
X
|
|
|
喜欢使用 single-page code 模型来开发网站页面。而不是使用code-behind 模型来编写网站页面
|
|
X
|
|
喜欢采用下面的方式编写网站：
在编写页面时候，为了可以快速的看到编写效果，动态编译该页面，马上可以看到效果，不用编译整个站点。 （就是说，只需要保存文件，然后在浏览器中刷新一下，就可以看到自己刚刚做的效果） |
|
X
|
|
需要控制编译后应用程序集的名字
|
X
|
|
|
需要每个页面产生一个应用程序集
|
|
X
|
|
WEB页面或者WEB用户控件中需要使用到单独的类。
|
X
|
|
|
需要使用多个Project来构建一个Web应用。
|
X
|
|
|
需要处理pre-build 和 post-build 事件（编译前后需要有自己额外的处理）
|
X
|
|
|
希望把一个目录当作一个WEB应用来处理，而不需要新建一个Project 文件。
|
|
X
|
这两种WEB编程模型的不同点：
|
Scenario
|
Web Application Project
|
Web Site Project
|
|
Project definition
|
跟 Visual Studio .NET 2003 类似，由于项目文件的存在，
只有被项目文件所引用的文件才会在Solution Explorer中出现。而且只有这些文件才会被编译。 可以很容易的把一个ASP.NET应用拆分成多个Visual Studio项目。 可以很容易的从项目中和源代码管理中排除一个文件。 |
一个目录结构就是一个WEB项目。没有项目文件存在。这个目录下的所有文件，都被作为项目的一部分而存在。
我们实际部署的一个网站，部署上当然不会有任何项目文件存在，如果你想对这个网站进行修改，用这种编程模型就非常适合。我们根本不用在乎这个WEB站点中，那些文件属于哪个项目。
|
|
编译和生成
|
跟Visual Studio .NET 2003的Web应用项目编译模式几乎一样。
项目中的所有的code-behind 类文件和独立类文件都被编译成一个独立应用程序集。这个应用程序集被放在Bin目录下。因为是一个独立的应用程序集，你能够指定应用程序集的名字、版本、输出位置等信息。
例如：Model-View-Controller (MVC) 模式就可以在这里很好的被使用。因为它允许在WEB页面和WEB用户控件中引用一个独立的类。
|
编译（Build）命令仅仅是测试这个WEB站点是否编译正确，调试一个WEB站点项目的时候，是通过依赖你的源代码文件，ASP.net进行动态编译页面和类来实现的。
预编译站点和动态编译站点用的是同一个 compilation semantics ，你可以通过预编译来提高站点的性能。
ASP.net 动态编译系统提供了两种模型：默认的batch 编译模型和fixed-names 编译模型。 batch 编译模型中，被编译成多个应用程序集（典型的是每一个目录被编译成一个）。这时候你看应用程序集，很难对应上是哪个目录。 fixed-names 编译模型中，网站的每个页面或者每个用户控件被编译成一个应用程序集。 |
|
Iterative development
|
调试或者运行Web页面的时候，你必须全部编译整个WEB项目。
编译整个WEB项目通常比较快，因为Visual Studio使用了增量编译模式，仅仅只有文件被修改后，这部分才会被增量编译进去。 |
你可以配置Visual Studio 2005的编译属性：编译整个站点、编译一个指定页面、或者什么都不作。在最后一种情况下，当你运行一个WEB站点的时候，Visual Studio 仅打开一个浏览器，并访问当前或者起始页，当这个请求被发送后，ASP.net 才开始动态编译。
这种模式下，页面被动态编译或者被编译成不同应用程序集，所以如果你调试或者运行一个页面的时候，不需要整个项目被编译通过。有错误的部分跟你使用的部分可以互不干扰。
默认情况下，当你运行或调试任何WEB页的时候，Visual Studio完全编译Web Site项目。 这么做可以看到编译时的所有错误。但是，在开发进程中，完全编译整个站点会是相当慢的。所以推荐你在开发调试中，只编译当前页。 |
|
部署
|
因为所有的类文件被编译成一个应用程序集，当你部署的时候，只需要把这个应用程序集和 .aspx文件、.ascx文件以及其它静态内容文件一起部署。
这种模型下，.aspx 文件将不被编译，当浏览器访问这个页面的时候，才会被动态编译。
不过，如果你使用Web Deployment Projects (一个Visual Studio 2005的插件，没有被默认包含到VS2005中),你就可以把 .aspx 文件也编译进入一个应用程序集中。 （大家提到的可以将前台页面编译到DLL的方法，其实还有另外一种方法，详可参考：http://aminic.blog.hexun.com/554026_d.html）
如果你只修改了小小的一行代码，你也需要把整个项目的所有代码都编译，并且发布包含所有代码的这个应用程序集。 |
使用Visual Studio 的 Publish Website 命令，你可以把.aspx 文件 和 code-behind 文件编译成应用程序集，所以你看到的编译后的 .aspx 文件头发生了变化。（注意：Build 命令并不会给你可部署的应用程序集）
最新版本的 Publish 将支持仅编译 code-behind 文件，这样部署的时候，将不改变 .aspx 文件。 默认是在Bin目录下预编译成几个应用程序集，典型的是一个目录对应一个应用程序集。
fixed-names 部署选项可以让每一个WEB页面或者每个WEB用户控件创建一个应用程序集，这样每个页面都有一个可部署的应用程序集。但是，fixed-names 部署选项会增多应用程序集的个数，而且实际内存使用也会增大。 |
|
从Visual Studio .NET 2003升级
|
因为跟VS2003采用了一样的WEB项目开发模型，升级是非常非常简单的。
|
Web site 项目的编译选项不同导致了它跟Visual Studio .NET 2003WEB项目的极大不同。
虽然微软提供了一个转换向导，但是如果你的项目如果是一个复杂的VS2003项目，使用这个转换向导后，你还需要对照转换手册，做很多工作。 如果你要从VS2003升级，建议不要用这种WEB站点开发模版。而是使用Web application 项目。 |
codebehind和src的区别
以前开发项目的时候经常搞不清楚codebehind和src的区别，下面是我从网上摘下来的，供参考：
在 ASP.NET 中使用代码隐藏方法来设计Web 窗体，可使页代码能够更清晰地从 HTML 内容中分离到完全单独的文件中。
通常一个 @page 指令如下：
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="WebApplication1.WebForm1" %>
其中有三个属性（Inherits、Src、CodeBehind）非常容易混淆，下面分别给予说明。
Inherits
Inherits 属性用于定义当前 Web 窗体所继承的代码隐藏类(该类是 System.Web.UI.Page 的派生类)。
这个 inherits 属性只用于采用代码隐藏方式编写的 Web 窗体，也就是，如果你的代码全都是在 Web 窗体的
<script runat="server"></script> 标签中，就不必用这个属性了。
Src
Src 属性用于指定“代码（隐藏）文件”在文件系统中的位置，以便于 ASP.NET Framework 用 Just-In-Time (JIT)
编译器动态编译 Web 窗体时能够找到它。用 Inherits 指明的类，就是放在这个类代码（隐藏）文件中。
通常 ASP.NET Framework 使用这些类时，首先会到已编译的程序集中查找，
如果找不到就会把在 Src 属性中提供的代码文件重新编译，所以 Src 属性和 Inherits 属性并不互斥。
需要说明的是，Visual Studio .NET 并不使用 Src 属性，
这就意味着 Visual Studio .NET 总是指望你用“生成”菜单中的生成操作来产生已编译的程序集
（通常是编译成DLL放在/bin目录中，这样一来，在发布应用系统时，就可以不用发布源代码了），
而以后不会发生需要动态编译的情况。所以如果你是在 Visual Studio .NET IDE 中开发的话，
要时常注意用“重新生成”功能来编译发生变动的类，否则，将会发生诸如找不到类呀什么的一系列问题。
Codebehind
呵呵，Codebehind 属性并不是一个真正的 ASP.NET 属性，在ASP.NET 文档中是找不到它的。
它其实只是一个 Visual Studio .NET 属性，
Visual Studio .NET 就是借用这个属性来很好地跟踪管理项目中的 Web 窗体和与之相对的代码隐藏文件，
比如当你在设计环境中往 Web 窗体上放入一个服务器控件时，
Visual Studio .NET 将自动找到与该 Web 窗体相对应的代码隐藏文件，并自动插入相关的代码。
因此，用 Visual Studio .NET 作开发时，不可轻率地将 Codebehind 属性换成 Src 属性，他们的功能作用不同。
