🎰 😽 🔷 编译网站和Web应用程序之间的差异 🌒 🌤️ 👨🏻‍🔧

基于各种平台的ASP.NET模块种类很多，例如Web窗体，Web页，模型视图控制器（MVC）和最新的Core。在本文中，我想看看编译ASP.NET网站和ASP.NET Web应用程序之间的许多差异。

网站（图1）和Web应用程序（图2）的编译。

图 1：ASP.NET网站以及ASP.NET网站和ASP.NET Web应用程序之间的区别

图 2：ASP.NET Web应用程序以及ASP.NET网站和ASP.NET Web应用程序之间的区别

本文不是关于ASP.NET项目的内部结构，而是关于我在Azure App Service平台上工作时获得的经验。内部设备已在此处进行了说明 -“预编译网站（C＃）”（“使用C＃预编译网站”）。您必须了解自动编译与显式编译之间的区别。另外，如果要处理ASP.NET网站，请认真考虑使用aspnet_compiler.exe进行预编译，如如何：预编译ASP.NET网站（如何预编译网站）中所述。 ASP.NET”）。

以下是一些出版物，可以帮助您拓宽对这一问题的视野并探索其他主题：

那一切从哪里开始呢？我想检查我是否了解正确将ASP.NET模块编译为程序集的过程，并决定在Azure App Service环境中进行此操作。我已经有了关于临时ASP.NET文件，将ASPX文件编译成.dll程序集以及关于它们在独立服务器上存储的位置的概念。我确信在App Service平台上，前两点是以类似的方式实现的，但是我怀疑第三点-即已编译程序集的存储位置。所以我写了一个代码找出来。

public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } }      () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater>

然后，我将此代码发布在App Service平台上。

当我第一次访问该网站时，结果如图所示。 3（最初在我的ASP.NET网站的根目录是三页）

图 3：在Azure App Service平台上编译ASP.NET网站

我重新启动了网站，并将二进制文件编译到一个新程序集中（图4）。这是非常出乎意料的，因为我仅重新启动并且没有进行任何部署或更改。

图 4：在Azure App Service平台上编译ASP.NET网站

我在KUDU中搜索了程序集目录，但没有找到它。这很奇怪。

单击“另一个页面”和“另一个页面”链接后，我的所有页面都被编译为一个程序集，我很惊讶地发现了这一点，因为在我的web.config文件中设置了debug = true。

我需要找出以下问题的答案：

尽管我没有执行任何部署或配置更改，为什么重启后我的应用程序仍会重新编译？
为什么即使我的源代码正确，我仍未在KUDU中找到程序集？
尽管在web.config文件中设置了debug = true，为什么我的应用程序被编译为单个程序集？

第一个问题的答案是，我实际上是在看KUDU程序集，而不是为App Service编译的程序集。请参阅文章 “为运行缓慢的Web App创建内存转储”中的图2。这表明KUDU与App Service运行的进程不同。因此，KUDU在创建实例时会自行重新编译，而不是我的App Service实例。

我还根据在第一个问题上收到的信息来整理出第二个问题。我将省略有关App Service平台上文件配置的详细信息，并说我能够在此平台上显示我的ASP.NET网站程序集：为此，我将WEBSITE_DISABLE_SCM_SEPARATION设置为true（参见图5）。这样做仅用于测试和（或）调试，仅此而已。我不建议将网站的多个页面映射到App Service中的单个进程。调试完成后，重置此值并再次分离过程。

图 5：在Azure App Service中编译ASP.NET网站； 我在KUDU上找不到临时的ASP.NET文件

第三个问题的答案是，如果存在Web.Debug.config文件，则在部署过程中将删除debug = true属性。

 <compilation xdt:Transform="RemoveAttributes(debug)" />

我在这里，这里和这里写了有关XDT文件的信息，但是在这种情况下，我不得不花点时间来理解（记住，意识到）它们的含义。

将WEBSITE_DISABLE_SCM_SEPARATION设置为true之后，我停止并启动，换句话说，是冷启动...，我发现SCM / KUDU和我的网站实际上是在同一过程中启动的（图6）。

图 6：在Azure App Service中编译ASP.NET网站； 我在KUDU上找不到临时的ASP.NET文件

将启动default.aspx的发布和编译，在所有请求之后，程序集名称均保持不变（图7）。

图 7：在Azure App Service平台上编译ASP.NET网站

为了验证这一点，我对进程内存进行了转储，对模块进行了转储，并对其进行了分析。老实说，我仍然对程序集显示的结果感到困惑，因为只有在完成所有测试之后，我才知道debug = true参数。有时我会以错误的顺序写文章，从而导致事件发生。感到困惑，我决定测试批处理编译。在此处阅读有关内容：“编译元素（ASP.NET设置架构）”（“编译元素-ASP.NET Web参数方案”）。我希望每页可以编译一个程序集，因此结果（见图8）是一个完全的惊喜。

图 8：在Azure App Service平台上编译ASP.NET网站

我希望每页看到一个程序集，因为我认为我正在使用debug = true参数。阅读有关批处理编译的知识，我意识到它会将所有页面编译到特定目录中包含的程序集中。因此，我创建了两个目录，并将.aspx文件放在每个目录中。 PID不变，因此没有“冷启动”（图9）。