ASP.NET网站还是ASP.NET网络应用程序?
ASP.NET网站还是ASP.NET网络应用程序?
当我在Visual Studio中开始一个新的ASP.NET项目时,我可以创建一个ASP.NET Web应用程序或者我可以创建一个ASP.NET网站。
ASP.NET Web应用程序和ASP.NET Web网站之间的区别是什么?为什么会选择其中一个?
基于我使用的Visual Studio版本,答案是否不同?
网站是部署到像IIS这样的ASP.NET Web服务器上的一堆文件和文件夹。在Web Site中没有与Visual Studio(没有项目文件)捆绑的内容。网页(例如.aspx、.ascx、.master)的代码生成和编译是在运行时动态完成的,对这些文件的更改会被框架检测到并自动重新编译。您可以将希望在页面之间共享的代码放在特殊的 App_Code 文件夹中,或者将其预编译并将程序集放在 Bin 文件夹中。
Web 应用程序是一个特殊的 Visual Studio 项目。与 Web Site 的主要区别在于构建项目时,所有代码文件都被编译为单个程序集,该程序集放置在 bin 目录中。您无需将代码文件部署到 Web 服务器上。您可以将共享代码文件放置在任何位置,就像在类库中一样。由于 Web 应用程序包含不打算部署的文件,例如项目和代码文件,在 Visual Studio 中有一个发布命令可将 Web Site 输出到指定位置。
App_Code vs Bin
部署共享代码文件通常不是一个好主意,但这并不意味着您必须选择使用 Web 应用程序。您可以拥有一个 Web Site,它引用一个持有 Web Site 所有代码的类库项目。Web 应用程序只是一种方便的方法。
CodeBehind
本主题适用于.aspx和.ascx文件。但是在新的应用程序框架中,如ASP.NET MVC和ASP.NET Web Pages中不使用CodeBehind文件,因此本主题越来越不相关。
通过将所有代码文件编译为单个程序集,包括.aspx页面和.ascx控件的CodeBehind文件,在Web应用程序中,您必须为每个小更改重新构建,并且不能进行实时更改。在开发过程中,这可能会导致很大的麻烦,因为您必须不断地重新构建以查看更改,而在Web网站中,运行时会检测到更改,并自动重新编译页面/控件。
让运行时管理CodeBehind程序集对您来说是更少的工作,因为您不需要担心为页面/控件提供唯一名称,或将它们组织到不同的命名空间中。
我并不是说部署代码文件总是一个好主意(特别是在共享代码文件的情况下),但是CodeBehind文件应该仅包含执行特定UI任务、连线事件处理程序等的代码。您的应用程序应该分层,以便重要代码始终出现在Bin文件夹中。如果这是的情况,那么部署CodeBehind文件就不应该被认为是有害的。
Web应用程序的另一个限制是,您只能使用项目的语言。在Web网站中,您可以在C#,VB等语言中拥有一些页面。无需特殊的Visual Studio支持。这就是Build Provider可扩展性的美。
此外,在Web应用程序中,您无法在页面/控件中获取错误检测,因为编译器只编译CodeBehind类,而不是标记代码(在MVC中,您可以使用MvcBuildViews选项解决此问题),在运行时进行编译。
Visual Studio
由于 Web 应用程序是 Visual Studio 项目,所以你可以得到一些 Web 站点中不可用的功能。例如,你可以使用构建事件执行各种任务,例如,缩小组合 Javascript 文件。
另一个 Visual Studio 2010 引入的好功能是Web.config 转换。在 VS 2013 中也适用于 Web 站点。
构建 Web 应用程序比构建 Web 站点要快,特别是对于大型站点来说。这主要是因为 Web 应用程序不会编译标记代码。在 MVC 中,如果将 MvcBuildViews 设置为 true,则它会编译标记代码,并且可以获得错误检测,这非常有用。不利的一面是每次构建解决方案都会构建完整的站点,这可能会很慢和低效,特别是如果你没有编辑该站点。我发现自己经常开关 MvcBuildViews(这需要项目卸载)。另一方面,对于 Web 站点,你可以选择是否将站点作为解决方案的一部分进行构建。如果不进行构建,那么构建解决方案就非常快,如果有更改,可以始终单击 Web 站点节点并选择“构建”。
在 MVC Web 应用程序项目中,你有额外的命令和对话框用于常见任务,如“添加视图”、“转到视图”、“添加控制器”等。这些在 MVC Web 站点中不可用。
如果将 IIS Express 用作开发服务器,可以在 Web 站点中添加虚拟目录。在 Web 应用程序中不可用。
NuGet Package Restore在Web Sites上不起作用,您必须手动安装在packages.config中列出的软件包。自NuGet 2.7起,Package Restore现在可以在Web Sites上使用。 (参见NuGet文档)
网站:
网站项目是即时编译的。这样会生成更多的DLL文件,而且很麻烦。而且,当你在一个目录中拥有页面或控件需要引用另一个目录中的页面和控件时,可能会出现问题,因为另一个目录可能尚未被编译进代码中。另一个问题可能出现在发布阶段。
如果没有告诉Visual Studio要不断重复使用相同的名称,它就会不断为页面生成的DLL文件命名新的名称。这可能会导致含有相同类名的多个DLL文件,从而产生大量错误。网站项目是在Visual Studio 2005中引入的,但是事实证明它并不受欢迎。
Web应用程序:
Web应用程序项目是作为一个插件创建的,现在作为Visual Studio 2005的SP 1的一部分存在。主要区别在于Web应用程序项目的设计与Visual Studio 2003一起提供的Web项目类似。它会在构建时将应用程序编译成单个DLL文件。要更新此项目,必须重新编译并发布DLL文件以使更改生效。
Web应用程序项目的另一个好处是更容易从项目视图中排除文件。在Web站点项目中,每个被排除的文件都会在文件名中带有一个被排除的关键词。在Web应用程序项目中,项目只是跟踪从项目视图中包含/排除哪些文件,而不会将它们重命名,使事情变得更整洁。
这篇文章ASP.NET 2.0 - Web Site vs Web Application project也提出了使用一种而不是另一种的原因。以下是摘录的部分内容:
- 需要将大型Visual Studio .NET 2003应用程序迁移到VS 2005?使用Web Application project。
- 想要打开和编辑任何目录作为Web项目而无需创建项目文件?使用Web Site project。
- 需要在编译期间添加预构建和后构建步骤?使用Web Application project。
- 需要使用多个Web项目构建Web应用程序?使用Web Application project。
- 想要为每个页面生成一个程序集?使用Web Site project。
- 喜欢动态编译并在不构建整个站点的情况下处理页面?使用Web Site project。
- 更喜欢单页代码模型而不是代码后置模型?使用Web Site project。
Web Application Projects versus Web Site Projects (MSDN)解释了网站和Web应用程序项目之间的区别。此外,它还讨论了在Visual Studio中要进行的配置。