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 Deploy (AzureRmWebAppDeployment) 任务进行发布，但无法在 Azure App Service 环境中加载，并使用 500.32 exception：

500.31 ANCM 未能找到本机依赖项

此问题的常见解决方案：

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

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

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

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

Other threads suggest looking for those details in the Windows Event Viewer (and here as well)。由于这是一项 Azure 应用服务，因此我查看了 应用服务日志。然而，那些只包括上述错误的副本，没有任何进一步的细节。此外，Azure Application Insights 中没有记录异常，这表明此错误是在 Application Insights 加载之前发生的。

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

Answer 1

应用服务日志与Windows事件查看器不同；它们将捕获异常，并且对于排除您没有看到的错误很有用，但它们至少不会为 ANCM 错误提供额外信息。相反，您需要确保启用详细错误，以确保您也收到由 ANCM 检测到的特定错误。

启用详细错误

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

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

在这种情况下，您只需将应用服务配置的 ASPNETCORE_ENVIRONMENT 配置变量更改为 Development。

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

检测到特定错误

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

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 运行时（在我的例子中是 .NET Core 3.1），它仍然试图从 .NET Core 2.1 运行时加载旧版依赖项，从而触发此错误。但是，除非您首先启用 UseDeveloperExceptionPage()，否则您将无法确定该依赖项对 Azure 应用服务的依赖。

解决问题

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

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

Answer 2

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