Visual Studio中“网站”和“项目”之间的区别
可能重复：
ASP.NET：网站或Web应用程序？
我注意到，当你启动Visual Studio 2008并select' New Project ' – >'ASP.NET Web Application'而不是' New Web Site ' – >'ASP.NET Web Site ”。 例如，如果您select“项目”，那么您可以编译为.dll，每个页面获取一个* .aspx.designer.cs代码隐藏文件。
1）为什么我们有这两种不同的项目types？
2）你喜欢哪一个？
3）为什么我会select一个呢？
4）什么处理* .aspx.designer.cs文件？
1）“网站”模型是在ASP.NET 2.0中引入的，“networking应用”模型是原始.net框架的项目types。 他们都有不同的用途（见下文）。
2）这取决于上下文。 一个很好的例子是，如果您销售的是软件产品，您可能希望使用“Web应用程序”项目，因为它自然适合干净编译的代码。
3）见上面，个人喜好，维护特点。 一个有趣的事情，一个“网站”允许你这样做会给你带来很多麻烦，在网站运行时，会在记事本中对代码隐藏文件（通常是* .cs或* .vb）文件进行随意更改。
4）designer.cs文件用于存储自动生成的代码。 “这个代码是由一个工具生成的。”
- MSDN文章描述的差异
- 类似的stackoverflow问题
他们有不同的目的。
网站是一个网站，其内容可能随时间而改变，即网页本身将会改变。 没有实际的项目文件，站点被简单地configuration为一组文件。
应用程序是一个内容只是应用程序的网站，dynamic的部分将主要存在于数据库等持久存储中。 它将会有更复杂的逻辑，因为它可能代表一组数据input的forms，也是一种检查内容的手段。 它有一个项目文件，以更严格地控制其configuration和其代码部署为编译的DLL。
我不会重复2的定义，因为刚刚得到答案。
那么为什么使用一个呢？
网站让你把它当作一个PHP或者传统的ASP站点，在那里你可以做内联的改变立即生效。
优点
- 您可以在Web服务器上对网站进行调整
- 部署与复制文件夹一样简单
缺点
- 如果您没有在实时网站上进行更改，则可能会遇到更改pipe理问题，您忘记保持所有文件同步
- 您可以将运行时语法错误显示给最终用户，因为检查的唯一方法是手动运行每个页面
Web应用程序让您更像对待桌面应用程序 – 在您的计算机上有一个可部署的应用程序。
优点
-
清晰，结构化的变更pipe理。 你不能不小心混合来自两个不同版本的代码。 当有两个人参与时，这可能很重要 – 一个是编写代码，另一个负责将文件放在服务器上。
-
因为你在你的机器上编译它，所以在这一点上所有的语法都被检查了*
缺点
-
部署更复杂一点，然后从开发机器复制文件夹。 然而，“Publish”命令的使用极大地简化了将哪些文件复制到Web服务器的过程。
-
任何更改需要在您的机器上完成，编译，并发送到Web服务器的全新版本*
*如果您在构build选项中打开aspx / html文件，只会语法检查。 也可以在服务器上编辑这些文件，除非它们被编译到您的项目中。
3）WebApplication项目可以由MSBuild构build。 WebSites不（没有很多调整）。 如果您使用TeamSystem进行自动构build，那么这是一条可行的路线。
简单的答案如下：
- 新build网站 – 在页面被请求时在服务器上编译的页面后面创build代码。
- 新buildWeb项目 – 将预编译页面创build为一个或多个程序集（甚至是整个站点），并部署在服务器上。
场景＃1 – 如果黑客获得你的代码隐藏文件，任何数据库密码都是暴露的。 这些页面在请求时被编译。 您可以select将所有内容预先编译成一个大的程序集。 否则，服务器上的负载会更大。
场景＃2 – 如果黑客获得你的程序集，它们将被混淆。 混淆的组件更难以破解。 这些程序集是预编译的，从而减less了服务器上的负载。
了解更多信息：
Web应用程序项目简介
最大的区别是，没有人真正提到过（除了Annakata所提到的），就是将所有东西都编译成单个DLL的模型，可以完全控制应用程序生成的类。 你知道他们在哪里，并且始终可以从应用程序的其他任何地方引用它们。
对于单页模型，你不能这样做。 您必须通过在AppCode目录中创build“存根”类并在页面中inheritance这些类来解决这个问题，但即使这样做也不理想，并增加了复杂性。
如果你想开发一个错综复杂的dynamic网站，那么在运行时根据内容dynamic地加载大量的用户控件，你只会真正想出这个东西。 然后，差异是痛苦的清楚 – 因此，我们的发展大部分停滞在ASP 1.1，直到我们可以稍后回到同一模型。
NICH
网站是2003年的原始.NET做web开发的方式。 根据我的经验，他们是非常有问题的，因为缺乏项目定义，他们不能重用，并且存在模块化编码方面的问题，与TeamSystem集成和命名空间有关。 一对一与域绑定，缺乏真正的发布抽象会造成维护问题。
古老的“经典”的ASP代码隐藏方式是一个严重的问题，因为它再一次影响了代码的重用和testing，并且经常提到的允许热修复的好处 – 如果有的话 – 实际上是一个巨大的信号，说明你有一个失败的开发过程。 热修复的能力当然比不能，但这是你永远不想调用的东西。
你可能会说，网站模型的问题已经足够大了，MS给了我们networking应用程序。 就我个人而言，除了演示代码之外，我绝对不会使用它们。实际上，我甚至不会这么做。
从两者的经验谈起：“网站”用于没有testing方法的地方，没有CI服务器，以及鼓励和定期向特定页面提供“修补程序”的文化。 “Web应用程序”是遵循正确的软件方法的实际标准，并且存在unit testing（如果不是完整的TDD）和CI服务器，其重点在于编写干净的代码并在需要“修补程序”之前发现错误。
-
起初有一个Web应用程序项目（它的行为类似于当前的Web站点项目）。 他们改变了它，以反映一些用户的要求。 然而，人们希望旧的function，所以他们重新介绍了网站项目的行为像原来的Web应用程序项目。
-
我 – 和我的工作场所 – 更喜欢网站项目
-
我们喜欢网站的文件是文件系统中的文件（不需要手动添加）
-
不知道
这里有两篇文章我发现关于两个：
http://damieng.com/blog/2008/02/07/web-site-vs-web-application
http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx
注意：网站的许多问题已经通过Web部署项目得到解决
更新：修正了第一点，Web应用程序在那里
如果您的工作需要利用oo语言function（类层次结构，命名空间）或者需要在项目之间重用通用代码（数据访问，类库等），那么Web应用程序项目是唯一的方法。
网站项目（线索是名义上的）对于非复杂的“brochureware” 网站 （网页由静态内容组成）而言，只是非常有用，而不是web 应用程序 。
几乎没有什么区别，我强烈推荐使用网站模型。
主要区别在于一个网站，有些文件需要放在某些目录（代码文件需要放在'App_Code'目录下），除此之外，它是非常简单的。
如果编译部署的代码对你来说很重要，并且你想要一个DLL（与为网站进行正常发布时创build的几个DLL相反），那么你需要获得这个插件： http ：//msdn.microsoft.com/en-us/asp.net/aa336619.aspx
