Azure发布的不同合并设置有哪些权衡取舍？

Question

通过Visual Studio发布到Azure时，您可以选择预编译页面。有很多选择可以解释它的作用，但没有任何关于权衡的选择。

• 为什么我不检查＆＃39;允许[...]可更新＆＃39;？
• 为什么要合并到一个文件中？这更快吗？它加载速度更快或编译速度更快吗？

微软网站上有一些信息，但在上述几点上，他们并没有深入研究它。

https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx

Answer 1

我发现有关这些选项的信息散布在Microsoft文档的不同页面上。这是我通过把事情放在一起找到的：

为什么我不检查'允许预编译站点可更新'？

这可能会回答你的问题：

  

如果编译的站点是可更新的，则可以更新UI内容而无需重新编译站点。当网站可更新时，内容文件将保留在其原始文件夹中，并且仅合并关联的代码文件。如果站点不可更新，则从原始文件夹中删除.ascx，.master和.skin内容文件。 ASP.NET .aspx文件将替换为没有内容的标记文件。在这种情况下，UI内容和代码将合并。

来源：https://msdn.microsoft.com/en-us/library/bb397866.aspx

可更新站点存储UI内容的源文件，但不编译它。仅预编译非UI代码。这使得更新网站非常简单，因为您可以更改一个网页的代码，而无需预编译整个网站。这个选项的缺点是网页无法预编译，每次用户请求页面时都会编译（减去可能发生的缓存）。这会降低页面加载的性能。

为什么要合并到一个文件中？这更快吗？它加载速度更快或编译速度更快吗？

将文件合并在一起可以简化部署，因为上传的文件较少。它还允许更多优化，因为编译器可以在多个网页上进行批量优化。但是，在合并所有内容时，必须在每次更改时完全重新部署站点（而不是仅部署已更新的程序集）。

以下是每个选项权衡的概述：

将所有输出合并到单个程序集：将所有内容合并到一个文件中会使部署更容易，因为只有一个文件可以上载。所有内容都在同一个包中编译，这允许批量优化，使页面加载速度更快。但是，如果网站的某个部分发生变化，则必须再次上传整个网站。如果您的网站不是很大，那将是一个不错的选择。

将每个单独的文件夹输出合并到自己的程序集中：使部署更容易，同时避免在每次更改时上传整个站点。只需要重新编译和重新部署包含更新代码的文件夹。

将所有页面和控件输出合并到单个程序集：将所有UI放在同一个程序集中，而不合并与UI无关的代码。这使您可以更新与UI无关的代码，而无需重新部署UI代码。

不合并：编译代码文件，但未预编译所有UI内容。因此，每次用户请求页面时都会编译网页UI（减去可能发生的缓存），这会使页面加载更长时间。但是，由于未编译UI，因此如果需要编辑一个网页，则可以在生产服务器上上载特定文件的新版本，而无需重新编译网站的任何部分。这对于无法完全重新部署的大型网站来说非常有用。

不合并。为每个页面和控件创建一个单独的程序集：将每个页面编译到它自己的程序集中。您具有预编译代码的速度，但代价是阻止编译器在多个页面上进行批量优化（页面加载时间稍长）。

有关asp.net网站合并和编译的更多信息：

• ASP.NET Merge Tool (Aspnet_merge.exe)
• ASP.NET Compilation Tool (Aspnet_compiler.exe)

Answer 2

我只想在这里发帖，因为它可能与其他人有关。我在Azure中运行的ASP.NET Framework 4.7中有一个大型旧项目。

Azure上的页面“实时”编译存在很多问题。我的意思很多。即this。有时我碰到的页面没有经过预编译，Azure似乎耗尽了所有编译资源，导致整个应用程序崩溃。重新启动后，花了8（!!）分钟才可以处理第一击。本地只有30秒。

在Corona期间，我终于有时间转移到.NET Core-所有这些问题立即消失了。

尽管Microsoft表示他们将在很长一段时间内继续支持.NET Framework，但对我来说很明显，Microsoft对该项目不再有任何热情。我与Azure结合使用时遇到的问题很荒谬。

我强烈建议尽快迁移。即使是一个大型项目，也没有我以前想象的那么痛苦。