对Azure应用服务上的500.31 ANCM进行故障排除

Question

将项目从 ASP.NET Core 3.0 升级到 ASP.NET Core 3.1 后，我的应用程序停止在 Azure App Services 上工作—但使用 Azure DevOps Pipelines 中的连续部署发布时，仅 。 （Similar to another question，如果我直接从Visual Studio发布，它将继续有效。）

特别是，管道仍然可以使用 Azure App Service部署（AzureRmWebAppDeployment）任务进行发布，但是它无法使用{{3 }}：

500.31 ANCM无法找到本地依赖项

此问题的常用解决方案：

找不到指定版本的Microsoft.NetCore.App或Microsoft.AspNetCore.App。

现在，对于未安装.NET Runtime的情况，我非常熟悉此错误，这在Microsoft发布新版本后立即很常见。在这些情况下，典型的解决方案是：

1. 以应用程序的--self-contained版本发布，或者发布为
2. 启用适当的运行时作为 App服务扩展（如果可用）。

在这种情况下，我知道 .NET Core 3.1.2运行时在App Services环境中可用，并且还确认这些解决方案不能解决问题。这表明存在其他潜在错误。

500.32 exception（Other threads suggest looking for those details in the Windows Event Viewer）。由于这是Azure应用服务，因此我查看了应用服务日志。这些仅包括上述错误的副本，但是没有任何更多详细信息。此外， Azure Application Insights 中没有记录任何异常，表明此错误是在加载Application Insights之前发生的。

鉴于此，我的问题是：如何解决Azure应用服务上的500.31错误？

Answer 1

应用服务日志与 Windows事件查看器不相似；它们将捕获异常，并且对于排除您没有看到的错误很有用，但是至少它们不会为ANCM错误提供其他信息。取而代之的是，您需要确保启用了详细的错误，以确保您还收到了ANCM检测到的特定错误。

启用详细错误

在ASP.NET Core应用程序中，可以使用UseDeveloperExceptionPage()类中的Startup中间件来启用详细的错误。在标准的ASP.NET Core模板中，可以根据环境变量有条件地切换它们：

public class Startup {
  …
  public static void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
    if (env.IsDevelopment()) {
      app.UseDeveloperExceptionPage();
    }
  }
}

在这种情况下，您只需要将App Service配置的ASPNETCORE_ENVIRONMENT配置变量更改为Development。

注意：这样做会暴露有关 all 异常的详细信息，并可能导致潜在的安全漏洞。仅应在其他情况下受保护的开发环境中启用此功能，或在面向公众的服务器上将其作为临时故障排除技术启用。

检测到特定错误

就我而言，这暴露了以下内容：

500.31 ANCM无法找到本地依赖项

此问题的常用解决方案：

找不到指定版本的Microsoft.NetCore.App或Microsoft.AspNetCore.App。

ANCM检测到特定错误：

错误：找不到在应用程序依赖项清单（Project.deps.json）中指定的程序集：包：'Microsoft.Data.SqlClient'，版本：'1.0.19269.1'路径：'runtimes / win / lib / netcoreapp2.1 / Microsoft.Data.SqlClient.dll'

现在，您的应用程序正在寻找的确切基础依赖关系可能会有所不同。但是关键点在于，即使它能够加载正确的.NET Runtime（在我的情况下为.NET Core 3.1），它仍在尝试从.NET Core 2.1运行时加载旧版依赖项，从而触发此错误。但是除非首先启用UseDeveloperExceptionPage()，否则您将无法确定该依赖关系对Azure App Service的影响。

解决问题

实际的解决方案显然取决于您收到的确切错误。在这种情况下，提供对最新Microsoft.Data.SqlClient NuGet程序包的显式引用即可解决此问题，并允许Azure App Service正确显示站点。

也就是说，我仍然不清楚为什么在直接从Visual Studio直接发布时可以奏效，但是在通过Azure DevOps管道发布时却失败了。我知道使用dotnet publish的各种标志时所包含的依赖项之间可能会有细微的差异，因此我的假设是Visual Studio和 Azure App Service Deploy 任务调用的方式之间存在差异dotnet publish。

Answer 2

在我们的例子中，它是需要更新到 dotnet 5 的应用服务上的日志扩展。