1、web app有.csproj文件，web site没有，它就是一个目录。这点从“添加现有项目”和“添加现有网站”可看出来
2、web app编译成一个.dll，web site随机编译成许多.dll
其他呢？希望大家补充
12 个解决方案
#1
不过是一个叫Visual Studio的程序编辑器内置的2套模板。对于ASP.NET来说没有区别。
如同Word中“精美型简历”和“专业型简历”，你可以创建一个精美型简历再手工修改成专业型简历，或者自定义简历。或者说，无论什么模板，最终产生的都是Word文档。
所有类型的项目，都可以通过创建空白解决方案项目后一步一步手工实现。
如同Word中“精美型简历”和“专业型简历”，你可以创建一个精美型简历再手工修改成专业型简历，或者自定义简历。或者说，无论什么模板，最终产生的都是Word文档。
所有类型的项目，都可以通过创建空白解决方案项目后一步一步手工实现。
#2
楼上说得直白，web site内置了不错的模板，app_code等文件夹。其实本质上没有太大的差别
#3
楼上说得直白，web site内置了不错的模板，app_code等文件夹。其实本质上没有太大的差别
#4
我更多的时候是从市场角度来说，而不是从什么技术角度。搞网站和和搞应用的就有很大区别，主要是从收入模式上、从而开发模式和售后服务模式上都有区别。
这跟asp.net其实没有什么关系。不论是搞网站，还是搞企业应用，asp.net都是早几年就应该被淘汰的（应该被淘汰不意味着就没有人用它来做项目了），因为它那种动辄就从web服务器上去刷新html下来，甚至（更烂的）每一次回发都重新访问数据库等来产生html的做法，显然是早就不敌RIA、Ajax了。
这跟asp.net其实没有什么关系。不论是搞网站，还是搞企业应用，asp.net都是早几年就应该被淘汰的（应该被淘汰不意味着就没有人用它来做项目了），因为它那种动辄就从web服务器上去刷新html下来，甚至（更烂的）每一次回发都重新访问数据库等来产生html的做法，显然是早就不敌RIA、Ajax了。
#5
楼上说的很深奥啊，ASP.NET 现在用的地方很多。。
#6
web site 更改后可以立刻刷新就看到效果。是为了兼顾ASP程序员开发习惯而设立的。没有命名空间。
web application 必须关闭浏览器再打开，或者重新生成后刷新才可以看到修改后的效果。有命名空间。
web application 必须关闭浏览器再打开，或者重新生成后刷新才可以看到修改后的效果。有命名空间。
#7
we bsite一般做小型网站，web application则做比较大型一点的网站。
#8
一样吧
反正都是这么写
反正都是这么写
#9
发现还有一个差别，在web app中，增加web窗体，会生成.aspx.designer.cs，而web site只会有.aspx和.aspx.cs
#10
一直用 web aplication
#11
我一直用 web aplication
#12
优先选择 Web 应用程序项目的情况包括：
需要在不停止调试会话的情况下能够编辑代码。
需要对与 ASP.NET 页关联的类文件中的代码运行单元测试。
需要从独立类中引用与页和用户控件关联的类。
您希望在多个 Web 项目之间建立项目相关性。
您希望编译器为整个站点创建单个程序集。
您要控制为站点生成的程序集的名称和版本号。
需要使用 MSBuild 或 Team Build 编译项目。 例如，您可能希望添加预先生成和后期生成步骤。
需要避免将源代码放置在生产服务器上。
需要使用 Visual Studio 2010 中提供的自动化部署工具。
优先选择网站项目的情况包括：
需要在单个 Web 项目中同时包含 C# 和 Visual Basic 代码。 （默认情况下，是根据项目文件中的语言设置编译 Web 应用程序的。 可以设置例外情况，但相对较难。）
需要在 Visual Studio 中打开生产站点和使用 FTP 对其进行实时更新。
不希望必须显式编译项目才能部署项目。
如果预编译站点，您希望编译器为站点创建多个程序集，可以是每个页面或用户控件一个程序集，也可以是每个文件夹一个或多个程序集。
您希望能够通过仅将新版本复制到生产服务器，或通过在生产服务器上直接编辑文件来更新生产中的各个文件。
如果预编译站点，您希望能更新各 ASP.NET 网页（.aspx 文件），而无需重新编译整个网站。
您希望在生产服务器上保留源代码，以便用作附加备份副本。
下表总结了主要差异。
区域
Web 应用程序项目
网站项目
项目文件结构
Visual Studio 项目文件（.csproj 或 .vbproj）存储有关项目的信息，如项目中包含的文件列表和项目间的任何引用。
不存在项目文件（.csproj 或 .vbproj）。 文件夹结构中的所有文件自动包含在站点中。
编译
在用于开发或源代码控制的计算机上显式编译源代码。
默认情况下，编译代码文件（不包括 .aspx 和 .ascx 文件）会生成一个程序集。
源代码通常是在站点安装或更新后首次收到请求时在服务器上通过 ASP.NET 动态（自动）进行编译的。
可以预编译站点（在开发计算机或服务器上预先编译）。
默认情况下，编译会生成多个程序集。
命名空间
默认情况下，将显式命名空间添加到页面、控件和类中。
默认情况下，不将显式命名空间添加到页面、控件和类中，但您可以手动添加它们。
部署
将程序集复制到服务器。 程序集通过编译应用程序生成。
Visual Studio 提供多个与 IIS Web 部署工具集成的工具来自动执行许多部署任务。
您将应用程序源文件复制到已安装 IIS 的计算机上。
如果在开发计算机上预编译站点，您可以将通过编译产生的程序集复制到 IIS 服务器。
Visual Studio 提供了多个用于部署的工具，但是这些工具自动执行的部署任务的数量不如为 Web 应用程序项目提供的工具多。
项目文件结构
Web 应用程序项目使用 Visual Studio 项目文件（.csproj 或 .vbproj）来跟踪有关项目的信息。 除其他任务以外，这还使得指定项目中要包含或排除哪些文件，以及因此在生成期间编译哪些文件成为可能。
对于网站项目，文件夹结构中的所有文件会被自动视为包含在网站中。 如果您希望从编译中排除某些文件，必须从网站项目文件夹中移除文件或将其文件扩展名更改为不由 IIS 编译和提供的扩展名。
使用 Web 应用程序项目中的项目文件具有以下优点：
易于暂时从站点移除文件，但仍确保不会失去对它们的跟踪，因为这些文件保留在文件夹结构中。 例如，如果页面没有为部署准备就绪，您可以暂时从生成中排除它，而无需从文件夹结构中将其删除。 您可以部署编译的程序集，然后再次将文件包括在项目中。 这在使用源代码管理储存库时尤为重要。
在网站项目中使用无项目文件的文件夹结构具有以下优点：
您不必专门在 Visual Studio 中管理项目的结构。 例如，您可以通过使用 Windows 资源管理器将文件复制到项目中或从项目中删除文件。
编译
对于 Web 应用程序项目，通常在 Visual Studio 中生成项目，或通过使用不是生产 IIS 服务器的计算机上的 ASP.NET 批处理编译器生成项目。 项目中的所有代码隐藏类文件和独立类文件都编译为一个程序集，然后将其放在 Web 应用程序项目的 Bin 文件夹中。 （.aspx 和 .ascx 文件以与网站项目类似的方式进行动态编译。）
对于网站项目，您不必手动编译项目。 网站项目通常由 ASP.NET（在开发计算机和生产 IIS 服务器上）进行动态编译。 您可以在批处理编译模式（通常为每个文件夹生成一个程序集）和固定编译模式（通常为每个页面或用户控件生成一个程序集）之间选择。
Web 应用程序项目的编译模型具有以下优点：
您可以使用 MSBuild 来创建自定义批处理编译过程。
指定程序集特性（如名称和版本）非常简单。
事先编译可确保在生产服务器上编译站点期间用户无须等待。 （如果站点非常大，网站项目的动态编译可能需要花费大量时间。 动态编译在更新站点之后收到站点资源请求时发生，并且当编译所需资源时，触发编译的请求可能会被延迟。 如果延迟不可接受，则可以预编译站点。 但因此会失去动态编译的某些优点。）
您可以完全控制项目文件夹结构中放置代码文件的位置，以及项目中的类互相引用的方式。 （动态编译要求在整个站点中使用的所有类的源代码必须位于 App_Code 文件夹中。 您不能从 App_Code 中的类引用页面或用户控件类。）
网站项目的编译模型具有以下优点：
您可以测试特定的页面，而不管其他页面的状态。 这是因为运行单个页面不需要成功编译整个站点，仅需编译该页面和该页面所依赖的任何组件，如 App_Code 文件夹或 Global.asax 文件中的代码。 （在 Web 应用程序项目中，如果站点中任何位置存在编译错误，则不能创建程序集，因此不能进行测试，甚至连测试所编译站点的部分内容也不行。)
在生产中更新网站非常容易。 可以更新生产服务器上的各个源代码文件，而无需以显式方式重新编译站点。 即使由于编译错误其他文件未准备就绪，也可以更新各个为部署准备就绪的文件。 还可以直接在 Visual Studio 中打开生产 IIS 服务器上的网站，并实时更新该网站。
在某些情况下，预编译为多个程序集具有性能优势。 一个典型示例是具有许多页面，并为这些页面编写了大量代码的站点。 其中大多数页面极少被请求，只有某些页面经常受到使用。 如果将这样的站点编译成多个程序集，生产服务器就可以仅加载当前请求所需的程序集。 如果未请求某个页面，则不会加载其对应的程序集。
注意
网站项目和 Web 应用程序项目之间没有性能差异。 唯一明显的例外就是那些已经指出的例外，在实际使用时，它们仅适用于非常大的站点。 对网站的第一个请求可能需要对站点进行编译，这可能会导致延迟。 如果网站运行在内存不足的 IIS 服务器上，则将整个站点包含在一个程序集中所使用的内存可能会超过将站点包含在多个程序集中所需的内存。
部署
若要部署 Web 应用程序项目，需将通过编译该项目创建的程序集复制到 IIS 服务器。 相反，若要部署网站项目，通常是将项目源文件复制到 IIS 服务器。
Web 应用程序项目部署策略的优点包括：
可以避免将源代码部署到 IIS 服务器。 在某些情况下，例如在共享承载环境中，您可能会关注对 IIS 服务器上源代码进行的未经授权的访问。 （对于网站项目，可能通过在开发计算机上进行预编译并部署所生成的程序集而不是源代码来避免此风险。 不过，在这种情况下，会失去轻松更新站点的某些好处。）
除将程序集或代码复制到服务器之外，部署通常还涉及其他任务。 例如，数据库脚本可能必须在生产中运行，Web.config 文件中的连接字符串可能需要针对生产服务器进行更改。 Visual Studio 提供了一些处理 Web 应用程序项目以自动执行其中许多任务的工具，如一键式发布。 这些工具对于网站项目不可用。
网站项目部署策略的优点包括：
如果对 Web 应用程序进行少量更改，则不必重新部署整个应用程序。 而是可以只将更改过的文件复制到生产 IIS 服务器。 另外，还可在生产服务器上直接编辑文件。 （因为 Web 应用程序项目的代码文件将被编译成单个程序集文件，所以即使进行少量更改，也必须部署整个站点，除非更改只是针对 .aspx 或 .ascx 文件。）
需要在不停止调试会话的情况下能够编辑代码。
需要对与 ASP.NET 页关联的类文件中的代码运行单元测试。
需要从独立类中引用与页和用户控件关联的类。
您希望在多个 Web 项目之间建立项目相关性。
您希望编译器为整个站点创建单个程序集。
您要控制为站点生成的程序集的名称和版本号。
需要使用 MSBuild 或 Team Build 编译项目。 例如，您可能希望添加预先生成和后期生成步骤。
需要避免将源代码放置在生产服务器上。
需要使用 Visual Studio 2010 中提供的自动化部署工具。
优先选择网站项目的情况包括：
需要在单个 Web 项目中同时包含 C# 和 Visual Basic 代码。 （默认情况下，是根据项目文件中的语言设置编译 Web 应用程序的。 可以设置例外情况，但相对较难。）
需要在 Visual Studio 中打开生产站点和使用 FTP 对其进行实时更新。
不希望必须显式编译项目才能部署项目。
如果预编译站点，您希望编译器为站点创建多个程序集，可以是每个页面或用户控件一个程序集，也可以是每个文件夹一个或多个程序集。
您希望能够通过仅将新版本复制到生产服务器，或通过在生产服务器上直接编辑文件来更新生产中的各个文件。
如果预编译站点，您希望能更新各 ASP.NET 网页（.aspx 文件），而无需重新编译整个网站。
您希望在生产服务器上保留源代码，以便用作附加备份副本。
下表总结了主要差异。
区域
Web 应用程序项目
网站项目
项目文件结构
Visual Studio 项目文件（.csproj 或 .vbproj）存储有关项目的信息，如项目中包含的文件列表和项目间的任何引用。
不存在项目文件（.csproj 或 .vbproj）。 文件夹结构中的所有文件自动包含在站点中。
编译
在用于开发或源代码控制的计算机上显式编译源代码。
默认情况下，编译代码文件（不包括 .aspx 和 .ascx 文件）会生成一个程序集。
源代码通常是在站点安装或更新后首次收到请求时在服务器上通过 ASP.NET 动态（自动）进行编译的。
可以预编译站点（在开发计算机或服务器上预先编译）。
默认情况下，编译会生成多个程序集。
命名空间
默认情况下，将显式命名空间添加到页面、控件和类中。
默认情况下，不将显式命名空间添加到页面、控件和类中，但您可以手动添加它们。
部署
将程序集复制到服务器。 程序集通过编译应用程序生成。
Visual Studio 提供多个与 IIS Web 部署工具集成的工具来自动执行许多部署任务。
您将应用程序源文件复制到已安装 IIS 的计算机上。
如果在开发计算机上预编译站点，您可以将通过编译产生的程序集复制到 IIS 服务器。
Visual Studio 提供了多个用于部署的工具，但是这些工具自动执行的部署任务的数量不如为 Web 应用程序项目提供的工具多。
项目文件结构
Web 应用程序项目使用 Visual Studio 项目文件（.csproj 或 .vbproj）来跟踪有关项目的信息。 除其他任务以外，这还使得指定项目中要包含或排除哪些文件，以及因此在生成期间编译哪些文件成为可能。
对于网站项目，文件夹结构中的所有文件会被自动视为包含在网站中。 如果您希望从编译中排除某些文件，必须从网站项目文件夹中移除文件或将其文件扩展名更改为不由 IIS 编译和提供的扩展名。
使用 Web 应用程序项目中的项目文件具有以下优点：
易于暂时从站点移除文件，但仍确保不会失去对它们的跟踪，因为这些文件保留在文件夹结构中。 例如，如果页面没有为部署准备就绪，您可以暂时从生成中排除它，而无需从文件夹结构中将其删除。 您可以部署编译的程序集，然后再次将文件包括在项目中。 这在使用源代码管理储存库时尤为重要。
在网站项目中使用无项目文件的文件夹结构具有以下优点：
您不必专门在 Visual Studio 中管理项目的结构。 例如，您可以通过使用 Windows 资源管理器将文件复制到项目中或从项目中删除文件。
编译
对于 Web 应用程序项目，通常在 Visual Studio 中生成项目，或通过使用不是生产 IIS 服务器的计算机上的 ASP.NET 批处理编译器生成项目。 项目中的所有代码隐藏类文件和独立类文件都编译为一个程序集，然后将其放在 Web 应用程序项目的 Bin 文件夹中。 （.aspx 和 .ascx 文件以与网站项目类似的方式进行动态编译。）
对于网站项目，您不必手动编译项目。 网站项目通常由 ASP.NET（在开发计算机和生产 IIS 服务器上）进行动态编译。 您可以在批处理编译模式（通常为每个文件夹生成一个程序集）和固定编译模式（通常为每个页面或用户控件生成一个程序集）之间选择。
Web 应用程序项目的编译模型具有以下优点：
您可以使用 MSBuild 来创建自定义批处理编译过程。
指定程序集特性（如名称和版本）非常简单。
事先编译可确保在生产服务器上编译站点期间用户无须等待。 （如果站点非常大，网站项目的动态编译可能需要花费大量时间。 动态编译在更新站点之后收到站点资源请求时发生，并且当编译所需资源时，触发编译的请求可能会被延迟。 如果延迟不可接受，则可以预编译站点。 但因此会失去动态编译的某些优点。）
您可以完全控制项目文件夹结构中放置代码文件的位置，以及项目中的类互相引用的方式。 （动态编译要求在整个站点中使用的所有类的源代码必须位于 App_Code 文件夹中。 您不能从 App_Code 中的类引用页面或用户控件类。）
网站项目的编译模型具有以下优点：
您可以测试特定的页面，而不管其他页面的状态。 这是因为运行单个页面不需要成功编译整个站点，仅需编译该页面和该页面所依赖的任何组件，如 App_Code 文件夹或 Global.asax 文件中的代码。 （在 Web 应用程序项目中，如果站点中任何位置存在编译错误，则不能创建程序集，因此不能进行测试，甚至连测试所编译站点的部分内容也不行。)
在生产中更新网站非常容易。 可以更新生产服务器上的各个源代码文件，而无需以显式方式重新编译站点。 即使由于编译错误其他文件未准备就绪，也可以更新各个为部署准备就绪的文件。 还可以直接在 Visual Studio 中打开生产 IIS 服务器上的网站，并实时更新该网站。
在某些情况下，预编译为多个程序集具有性能优势。 一个典型示例是具有许多页面，并为这些页面编写了大量代码的站点。 其中大多数页面极少被请求，只有某些页面经常受到使用。 如果将这样的站点编译成多个程序集，生产服务器就可以仅加载当前请求所需的程序集。 如果未请求某个页面，则不会加载其对应的程序集。
注意
网站项目和 Web 应用程序项目之间没有性能差异。 唯一明显的例外就是那些已经指出的例外，在实际使用时，它们仅适用于非常大的站点。 对网站的第一个请求可能需要对站点进行编译，这可能会导致延迟。 如果网站运行在内存不足的 IIS 服务器上，则将整个站点包含在一个程序集中所使用的内存可能会超过将站点包含在多个程序集中所需的内存。
部署
若要部署 Web 应用程序项目，需将通过编译该项目创建的程序集复制到 IIS 服务器。 相反，若要部署网站项目，通常是将项目源文件复制到 IIS 服务器。
Web 应用程序项目部署策略的优点包括：
可以避免将源代码部署到 IIS 服务器。 在某些情况下，例如在共享承载环境中，您可能会关注对 IIS 服务器上源代码进行的未经授权的访问。 （对于网站项目，可能通过在开发计算机上进行预编译并部署所生成的程序集而不是源代码来避免此风险。 不过，在这种情况下，会失去轻松更新站点的某些好处。）
除将程序集或代码复制到服务器之外，部署通常还涉及其他任务。 例如，数据库脚本可能必须在生产中运行，Web.config 文件中的连接字符串可能需要针对生产服务器进行更改。 Visual Studio 提供了一些处理 Web 应用程序项目以自动执行其中许多任务的工具，如一键式发布。 这些工具对于网站项目不可用。
网站项目部署策略的优点包括：
如果对 Web 应用程序进行少量更改，则不必重新部署整个应用程序。 而是可以只将更改过的文件复制到生产 IIS 服务器。 另外，还可在生产服务器上直接编辑文件。 （因为 Web 应用程序项目的代码文件将被编译成单个程序集文件，所以即使进行少量更改，也必须部署整个站点，除非更改只是针对 .aspx 或 .ascx 文件。）
#1
不过是一个叫Visual Studio的程序编辑器内置的2套模板。对于ASP.NET来说没有区别。
如同Word中“精美型简历”和“专业型简历”，你可以创建一个精美型简历再手工修改成专业型简历，或者自定义简历。或者说，无论什么模板，最终产生的都是Word文档。
所有类型的项目，都可以通过创建空白解决方案项目后一步一步手工实现。
如同Word中“精美型简历”和“专业型简历”，你可以创建一个精美型简历再手工修改成专业型简历，或者自定义简历。或者说，无论什么模板，最终产生的都是Word文档。
所有类型的项目，都可以通过创建空白解决方案项目后一步一步手工实现。
#2
楼上说得直白，web site内置了不错的模板，app_code等文件夹。其实本质上没有太大的差别
#3
楼上说得直白，web site内置了不错的模板，app_code等文件夹。其实本质上没有太大的差别
#4
我更多的时候是从市场角度来说，而不是从什么技术角度。搞网站和和搞应用的就有很大区别，主要是从收入模式上、从而开发模式和售后服务模式上都有区别。
这跟asp.net其实没有什么关系。不论是搞网站，还是搞企业应用，asp.net都是早几年就应该被淘汰的（应该被淘汰不意味着就没有人用它来做项目了），因为它那种动辄就从web服务器上去刷新html下来，甚至（更烂的）每一次回发都重新访问数据库等来产生html的做法，显然是早就不敌RIA、Ajax了。
这跟asp.net其实没有什么关系。不论是搞网站，还是搞企业应用，asp.net都是早几年就应该被淘汰的（应该被淘汰不意味着就没有人用它来做项目了），因为它那种动辄就从web服务器上去刷新html下来，甚至（更烂的）每一次回发都重新访问数据库等来产生html的做法，显然是早就不敌RIA、Ajax了。
#5
楼上说的很深奥啊，ASP.NET 现在用的地方很多。。
#6
web site 更改后可以立刻刷新就看到效果。是为了兼顾ASP程序员开发习惯而设立的。没有命名空间。
web application 必须关闭浏览器再打开，或者重新生成后刷新才可以看到修改后的效果。有命名空间。
web application 必须关闭浏览器再打开，或者重新生成后刷新才可以看到修改后的效果。有命名空间。
#7
we bsite一般做小型网站，web application则做比较大型一点的网站。
#8
一样吧
反正都是这么写
反正都是这么写
#9
发现还有一个差别，在web app中，增加web窗体，会生成.aspx.designer.cs，而web site只会有.aspx和.aspx.cs
#10
一直用 web aplication
#11
我一直用 web aplication
#12
优先选择 Web 应用程序项目的情况包括：
需要在不停止调试会话的情况下能够编辑代码。
需要对与 ASP.NET 页关联的类文件中的代码运行单元测试。
需要从独立类中引用与页和用户控件关联的类。
您希望在多个 Web 项目之间建立项目相关性。
您希望编译器为整个站点创建单个程序集。
您要控制为站点生成的程序集的名称和版本号。
需要使用 MSBuild 或 Team Build 编译项目。 例如，您可能希望添加预先生成和后期生成步骤。
需要避免将源代码放置在生产服务器上。
需要使用 Visual Studio 2010 中提供的自动化部署工具。
优先选择网站项目的情况包括：
需要在单个 Web 项目中同时包含 C# 和 Visual Basic 代码。 （默认情况下，是根据项目文件中的语言设置编译 Web 应用程序的。 可以设置例外情况，但相对较难。）
需要在 Visual Studio 中打开生产站点和使用 FTP 对其进行实时更新。
不希望必须显式编译项目才能部署项目。
如果预编译站点，您希望编译器为站点创建多个程序集，可以是每个页面或用户控件一个程序集，也可以是每个文件夹一个或多个程序集。
您希望能够通过仅将新版本复制到生产服务器，或通过在生产服务器上直接编辑文件来更新生产中的各个文件。
如果预编译站点，您希望能更新各 ASP.NET 网页（.aspx 文件），而无需重新编译整个网站。
您希望在生产服务器上保留源代码，以便用作附加备份副本。
下表总结了主要差异。
区域
Web 应用程序项目
网站项目
项目文件结构
Visual Studio 项目文件（.csproj 或 .vbproj）存储有关项目的信息，如项目中包含的文件列表和项目间的任何引用。
不存在项目文件（.csproj 或 .vbproj）。 文件夹结构中的所有文件自动包含在站点中。
编译
在用于开发或源代码控制的计算机上显式编译源代码。
默认情况下，编译代码文件（不包括 .aspx 和 .ascx 文件）会生成一个程序集。
源代码通常是在站点安装或更新后首次收到请求时在服务器上通过 ASP.NET 动态（自动）进行编译的。
可以预编译站点（在开发计算机或服务器上预先编译）。
默认情况下，编译会生成多个程序集。
命名空间
默认情况下，将显式命名空间添加到页面、控件和类中。
默认情况下，不将显式命名空间添加到页面、控件和类中，但您可以手动添加它们。
部署
将程序集复制到服务器。 程序集通过编译应用程序生成。
Visual Studio 提供多个与 IIS Web 部署工具集成的工具来自动执行许多部署任务。
您将应用程序源文件复制到已安装 IIS 的计算机上。
如果在开发计算机上预编译站点，您可以将通过编译产生的程序集复制到 IIS 服务器。
Visual Studio 提供了多个用于部署的工具，但是这些工具自动执行的部署任务的数量不如为 Web 应用程序项目提供的工具多。
项目文件结构
Web 应用程序项目使用 Visual Studio 项目文件（.csproj 或 .vbproj）来跟踪有关项目的信息。 除其他任务以外，这还使得指定项目中要包含或排除哪些文件，以及因此在生成期间编译哪些文件成为可能。
对于网站项目，文件夹结构中的所有文件会被自动视为包含在网站中。 如果您希望从编译中排除某些文件，必须从网站项目文件夹中移除文件或将其文件扩展名更改为不由 IIS 编译和提供的扩展名。
使用 Web 应用程序项目中的项目文件具有以下优点：
易于暂时从站点移除文件，但仍确保不会失去对它们的跟踪，因为这些文件保留在文件夹结构中。 例如，如果页面没有为部署准备就绪，您可以暂时从生成中排除它，而无需从文件夹结构中将其删除。 您可以部署编译的程序集，然后再次将文件包括在项目中。 这在使用源代码管理储存库时尤为重要。
在网站项目中使用无项目文件的文件夹结构具有以下优点：
您不必专门在 Visual Studio 中管理项目的结构。 例如，您可以通过使用 Windows 资源管理器将文件复制到项目中或从项目中删除文件。
编译
对于 Web 应用程序项目，通常在 Visual Studio 中生成项目，或通过使用不是生产 IIS 服务器的计算机上的 ASP.NET 批处理编译器生成项目。 项目中的所有代码隐藏类文件和独立类文件都编译为一个程序集，然后将其放在 Web 应用程序项目的 Bin 文件夹中。 （.aspx 和 .ascx 文件以与网站项目类似的方式进行动态编译。）
对于网站项目，您不必手动编译项目。 网站项目通常由 ASP.NET（在开发计算机和生产 IIS 服务器上）进行动态编译。 您可以在批处理编译模式（通常为每个文件夹生成一个程序集）和固定编译模式（通常为每个页面或用户控件生成一个程序集）之间选择。
Web 应用程序项目的编译模型具有以下优点：
您可以使用 MSBuild 来创建自定义批处理编译过程。
指定程序集特性（如名称和版本）非常简单。
事先编译可确保在生产服务器上编译站点期间用户无须等待。 （如果站点非常大，网站项目的动态编译可能需要花费大量时间。 动态编译在更新站点之后收到站点资源请求时发生，并且当编译所需资源时，触发编译的请求可能会被延迟。 如果延迟不可接受，则可以预编译站点。 但因此会失去动态编译的某些优点。）
您可以完全控制项目文件夹结构中放置代码文件的位置，以及项目中的类互相引用的方式。 （动态编译要求在整个站点中使用的所有类的源代码必须位于 App_Code 文件夹中。 您不能从 App_Code 中的类引用页面或用户控件类。）
网站项目的编译模型具有以下优点：
您可以测试特定的页面，而不管其他页面的状态。 这是因为运行单个页面不需要成功编译整个站点，仅需编译该页面和该页面所依赖的任何组件，如 App_Code 文件夹或 Global.asax 文件中的代码。 （在 Web 应用程序项目中，如果站点中任何位置存在编译错误，则不能创建程序集，因此不能进行测试，甚至连测试所编译站点的部分内容也不行。)
在生产中更新网站非常容易。 可以更新生产服务器上的各个源代码文件，而无需以显式方式重新编译站点。 即使由于编译错误其他文件未准备就绪，也可以更新各个为部署准备就绪的文件。 还可以直接在 Visual Studio 中打开生产 IIS 服务器上的网站，并实时更新该网站。
在某些情况下，预编译为多个程序集具有性能优势。 一个典型示例是具有许多页面，并为这些页面编写了大量代码的站点。 其中大多数页面极少被请求，只有某些页面经常受到使用。 如果将这样的站点编译成多个程序集，生产服务器就可以仅加载当前请求所需的程序集。 如果未请求某个页面，则不会加载其对应的程序集。
注意
网站项目和 Web 应用程序项目之间没有性能差异。 唯一明显的例外就是那些已经指出的例外，在实际使用时，它们仅适用于非常大的站点。 对网站的第一个请求可能需要对站点进行编译，这可能会导致延迟。 如果网站运行在内存不足的 IIS 服务器上，则将整个站点包含在一个程序集中所使用的内存可能会超过将站点包含在多个程序集中所需的内存。
部署
若要部署 Web 应用程序项目，需将通过编译该项目创建的程序集复制到 IIS 服务器。 相反，若要部署网站项目，通常是将项目源文件复制到 IIS 服务器。
Web 应用程序项目部署策略的优点包括：
可以避免将源代码部署到 IIS 服务器。 在某些情况下，例如在共享承载环境中，您可能会关注对 IIS 服务器上源代码进行的未经授权的访问。 （对于网站项目，可能通过在开发计算机上进行预编译并部署所生成的程序集而不是源代码来避免此风险。 不过，在这种情况下，会失去轻松更新站点的某些好处。）
除将程序集或代码复制到服务器之外，部署通常还涉及其他任务。 例如，数据库脚本可能必须在生产中运行，Web.config 文件中的连接字符串可能需要针对生产服务器进行更改。 Visual Studio 提供了一些处理 Web 应用程序项目以自动执行其中许多任务的工具，如一键式发布。 这些工具对于网站项目不可用。
网站项目部署策略的优点包括：
如果对 Web 应用程序进行少量更改，则不必重新部署整个应用程序。 而是可以只将更改过的文件复制到生产 IIS 服务器。 另外，还可在生产服务器上直接编辑文件。 （因为 Web 应用程序项目的代码文件将被编译成单个程序集文件，所以即使进行少量更改，也必须部署整个站点，除非更改只是针对 .aspx 或 .ascx 文件。）
需要在不停止调试会话的情况下能够编辑代码。
需要对与 ASP.NET 页关联的类文件中的代码运行单元测试。
需要从独立类中引用与页和用户控件关联的类。
您希望在多个 Web 项目之间建立项目相关性。
您希望编译器为整个站点创建单个程序集。
您要控制为站点生成的程序集的名称和版本号。
需要使用 MSBuild 或 Team Build 编译项目。 例如，您可能希望添加预先生成和后期生成步骤。
需要避免将源代码放置在生产服务器上。
需要使用 Visual Studio 2010 中提供的自动化部署工具。
优先选择网站项目的情况包括：
需要在单个 Web 项目中同时包含 C# 和 Visual Basic 代码。 （默认情况下，是根据项目文件中的语言设置编译 Web 应用程序的。 可以设置例外情况，但相对较难。）
需要在 Visual Studio 中打开生产站点和使用 FTP 对其进行实时更新。
不希望必须显式编译项目才能部署项目。
如果预编译站点，您希望编译器为站点创建多个程序集，可以是每个页面或用户控件一个程序集，也可以是每个文件夹一个或多个程序集。
您希望能够通过仅将新版本复制到生产服务器，或通过在生产服务器上直接编辑文件来更新生产中的各个文件。
如果预编译站点，您希望能更新各 ASP.NET 网页（.aspx 文件），而无需重新编译整个网站。
您希望在生产服务器上保留源代码，以便用作附加备份副本。
下表总结了主要差异。
区域
Web 应用程序项目
网站项目
项目文件结构
Visual Studio 项目文件（.csproj 或 .vbproj）存储有关项目的信息，如项目中包含的文件列表和项目间的任何引用。
不存在项目文件（.csproj 或 .vbproj）。 文件夹结构中的所有文件自动包含在站点中。
编译
在用于开发或源代码控制的计算机上显式编译源代码。
默认情况下，编译代码文件（不包括 .aspx 和 .ascx 文件）会生成一个程序集。
源代码通常是在站点安装或更新后首次收到请求时在服务器上通过 ASP.NET 动态（自动）进行编译的。
可以预编译站点（在开发计算机或服务器上预先编译）。
默认情况下，编译会生成多个程序集。
命名空间
默认情况下，将显式命名空间添加到页面、控件和类中。
默认情况下，不将显式命名空间添加到页面、控件和类中，但您可以手动添加它们。
部署
将程序集复制到服务器。 程序集通过编译应用程序生成。
Visual Studio 提供多个与 IIS Web 部署工具集成的工具来自动执行许多部署任务。
您将应用程序源文件复制到已安装 IIS 的计算机上。
如果在开发计算机上预编译站点，您可以将通过编译产生的程序集复制到 IIS 服务器。
Visual Studio 提供了多个用于部署的工具，但是这些工具自动执行的部署任务的数量不如为 Web 应用程序项目提供的工具多。
项目文件结构
Web 应用程序项目使用 Visual Studio 项目文件（.csproj 或 .vbproj）来跟踪有关项目的信息。 除其他任务以外，这还使得指定项目中要包含或排除哪些文件，以及因此在生成期间编译哪些文件成为可能。
对于网站项目，文件夹结构中的所有文件会被自动视为包含在网站中。 如果您希望从编译中排除某些文件，必须从网站项目文件夹中移除文件或将其文件扩展名更改为不由 IIS 编译和提供的扩展名。
使用 Web 应用程序项目中的项目文件具有以下优点：
易于暂时从站点移除文件，但仍确保不会失去对它们的跟踪，因为这些文件保留在文件夹结构中。 例如，如果页面没有为部署准备就绪，您可以暂时从生成中排除它，而无需从文件夹结构中将其删除。 您可以部署编译的程序集，然后再次将文件包括在项目中。 这在使用源代码管理储存库时尤为重要。
在网站项目中使用无项目文件的文件夹结构具有以下优点：
您不必专门在 Visual Studio 中管理项目的结构。 例如，您可以通过使用 Windows 资源管理器将文件复制到项目中或从项目中删除文件。
编译
对于 Web 应用程序项目，通常在 Visual Studio 中生成项目，或通过使用不是生产 IIS 服务器的计算机上的 ASP.NET 批处理编译器生成项目。 项目中的所有代码隐藏类文件和独立类文件都编译为一个程序集，然后将其放在 Web 应用程序项目的 Bin 文件夹中。 （.aspx 和 .ascx 文件以与网站项目类似的方式进行动态编译。）
对于网站项目，您不必手动编译项目。 网站项目通常由 ASP.NET（在开发计算机和生产 IIS 服务器上）进行动态编译。 您可以在批处理编译模式（通常为每个文件夹生成一个程序集）和固定编译模式（通常为每个页面或用户控件生成一个程序集）之间选择。
Web 应用程序项目的编译模型具有以下优点：
您可以使用 MSBuild 来创建自定义批处理编译过程。
指定程序集特性（如名称和版本）非常简单。
事先编译可确保在生产服务器上编译站点期间用户无须等待。 （如果站点非常大，网站项目的动态编译可能需要花费大量时间。 动态编译在更新站点之后收到站点资源请求时发生，并且当编译所需资源时，触发编译的请求可能会被延迟。 如果延迟不可接受，则可以预编译站点。 但因此会失去动态编译的某些优点。）
您可以完全控制项目文件夹结构中放置代码文件的位置，以及项目中的类互相引用的方式。 （动态编译要求在整个站点中使用的所有类的源代码必须位于 App_Code 文件夹中。 您不能从 App_Code 中的类引用页面或用户控件类。）
网站项目的编译模型具有以下优点：
您可以测试特定的页面，而不管其他页面的状态。 这是因为运行单个页面不需要成功编译整个站点，仅需编译该页面和该页面所依赖的任何组件，如 App_Code 文件夹或 Global.asax 文件中的代码。 （在 Web 应用程序项目中，如果站点中任何位置存在编译错误，则不能创建程序集，因此不能进行测试，甚至连测试所编译站点的部分内容也不行。)
在生产中更新网站非常容易。 可以更新生产服务器上的各个源代码文件，而无需以显式方式重新编译站点。 即使由于编译错误其他文件未准备就绪，也可以更新各个为部署准备就绪的文件。 还可以直接在 Visual Studio 中打开生产 IIS 服务器上的网站，并实时更新该网站。
在某些情况下，预编译为多个程序集具有性能优势。 一个典型示例是具有许多页面，并为这些页面编写了大量代码的站点。 其中大多数页面极少被请求，只有某些页面经常受到使用。 如果将这样的站点编译成多个程序集，生产服务器就可以仅加载当前请求所需的程序集。 如果未请求某个页面，则不会加载其对应的程序集。
注意
网站项目和 Web 应用程序项目之间没有性能差异。 唯一明显的例外就是那些已经指出的例外，在实际使用时，它们仅适用于非常大的站点。 对网站的第一个请求可能需要对站点进行编译，这可能会导致延迟。 如果网站运行在内存不足的 IIS 服务器上，则将整个站点包含在一个程序集中所使用的内存可能会超过将站点包含在多个程序集中所需的内存。
部署
若要部署 Web 应用程序项目，需将通过编译该项目创建的程序集复制到 IIS 服务器。 相反，若要部署网站项目，通常是将项目源文件复制到 IIS 服务器。
Web 应用程序项目部署策略的优点包括：
可以避免将源代码部署到 IIS 服务器。 在某些情况下，例如在共享承载环境中，您可能会关注对 IIS 服务器上源代码进行的未经授权的访问。 （对于网站项目，可能通过在开发计算机上进行预编译并部署所生成的程序集而不是源代码来避免此风险。 不过，在这种情况下，会失去轻松更新站点的某些好处。）
除将程序集或代码复制到服务器之外，部署通常还涉及其他任务。 例如，数据库脚本可能必须在生产中运行，Web.config 文件中的连接字符串可能需要针对生产服务器进行更改。 Visual Studio 提供了一些处理 Web 应用程序项目以自动执行其中许多任务的工具，如一键式发布。 这些工具对于网站项目不可用。
网站项目部署策略的优点包括：
如果对 Web 应用程序进行少量更改，则不必重新部署整个应用程序。 而是可以只将更改过的文件复制到生产 IIS 服务器。 另外，还可在生产服务器上直接编辑文件。 （因为 Web 应用程序项目的代码文件将被编译成单个程序集文件，所以即使进行少量更改，也必须部署整个站点，除非更改只是针对 .aspx 或 .ascx 文件。）