Azure 应用服务上的 500.31 ANCM 疑难解答 [英] Troubleshooting 500.31 ANCM on Azure App Service

问题描述

将项目从 ASP.NET Core 3.0 升级到 ASP.NET Core 3.1 后，我的应用程序停止在 Azure 应用服务上运行—但仅在使用Azure DevOps Pipelines的持续部署发布时.(类似于另一个问题，它继续如果我直接从 Visual Studio 发布就可以工作.)

具体来说，管道仍然可以使用 Azure App Service Deploy (AzureRmWebAppDeployment) 任务进行发布，但它无法在 Azure 应用服务环境中加载500.32 异常:

<块引用>

500.31 ANCM 无法找到本机依赖项

此问题的常见解决方案:

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

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

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

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

其他线程建议在 Windows 事件查看器中查找这些详细信息(这里也是).由于这是一项 Azure 应用服务，因此我查看了应用服务日志.然而，那些只包括上述错误的副本，没有任何进一步的细节.此外，Azure Application Insights 中没有记录异常，表明此错误是在 Application Insights 加载之前发生的.

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

解决方案

应用服务日志与 Windows 事件查看器不同；它们将捕获异常，并且对于排除您没有看到的错误很有用，但它们至少不会产生关于 ANCM 错误的附加信息.相反，您需要确保启用了详细错误，以确保您还获得ANCM 检测到的特定错误.

启用详细错误

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

public class Startup {…公共静态无效配置(IApplicationBuilder 应用程序，IWebHostEnvironment 环境){如果 (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 之间存在差异em> 任务调用 dotnet publish.

After upgrading a project from ASP.NET Core 3.0 to ASP.NET Core 3.1, my application stopped working on Azure App Services—but only when published using continuous deployment from Azure DevOps Pipelines. (Similar to another question, it continues to work if I publish directly from Visual Studio.)

Specifically, the pipeline is still able to publish using the Azure App Service Deploy (AzureRmWebAppDeployment) task, but it fails to load in the Azure App Service environment with a 500.32 exception:

500.31 ANCM Failed to Find Native Dependencies

Common solutions to this issue:

The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.

Now, I'm quite familiar with this error for cases where the .NET Runtime is not installed, as is common immediately after Microsoft releases new versions. In those cases, the typical solution is to either:

1. Publish as a --self-contained version of the application, or to
2. Enable the appropriate runtime as an App Service Extension, if available.

In this case, I know the .NET Core 3.1.2 runtime is available in the App Services environment, and have additionally confirmed that these solutions don't resolve the issue. This indicates a different underlying error.

Other threads suggest looking for those details in the Windows Event Viewer (and here as well). Since this is an Azure App Service, I instead looked in the App Service Logs. Those only included a copy of the above error, however, without any further details. Further, there are no exceptions logged in Azure Application Insights, suggesting this error is occurring prior to Application Insights loading.

Given this, my question: How do I troubleshoot 500.31 errors on an Azure App Service?

解决方案

The App Service Logs are not analogous to the Windows Event Viewer; they will capture the exceptions, and are useful for troubleshooting errors that you did not witness, but they won't yield additional information for ANCM errors, at least. Instead, you'll need to ensure that detailed errors are enabled in order to ensure that you're also getting the specific error detected by ANCM.

Enabling detailed errors

In an ASP.NET Core application, detailed errors can be enabled using the UseDeveloperExceptionPage() middleware in the Startup class. In a standard ASP.NET Core template, they can be conditionally toggled based on an environment variable:

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

In that case, you just need to change your App Service configuration's ASPNETCORE_ENVIRONMENT configuration variable to Development.

Note: Doing this exposes details about all exceptions and can lead to potential security vulnerabilities. This should only be enabled for otherwise-secured development environments, or as a temporary troubleshooting technique on a public-facing server.

Specific error detected

In my case, this exposed the following:

500.31 ANCM Failed to Find Native Dependencies

Common solutions to this issue:

The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.

Specific error detected by ANCM:

Error: An assembly specified in the application dependencies manifest (Project.deps.json) was not found: package: 'Microsoft.Data.SqlClient', version: '1.0.19269.1' path: 'runtimes/win/lib/netcoreapp2.1/Microsoft.Data.SqlClient.dll'

Now, the exact underlying dependency that your application is looking for will likely be different. But the critical point is that even though it's able to load the correct .NET Runtime (.NET Core 3.1 in my case), it's still trying to load a legacy dependency from the .NET Core 2.1 runtime, thus triggering this error. But you won't be able to determine what that dependency is on an Azure App Service unless you first enable the UseDeveloperExceptionPage().

Resolving the issue

The actual solution will obviously depend on the exact error you're receiving. In this case, providing an explicit reference to the latest Microsoft.Data.SqlClient NuGet package solves the problem, and allows the Azure App Service to display the site correctly.

That said, it remains unclear to me why this worked when publishing directly from Visual Studio, but fails when publishing via an Azure DevOps Pipeline. I know there can be subtle differences in what dependencies are included when using various flags of dotnet publish, so my assumption is that there's a difference between how Visual Studio and the Azure App Service Deploy task call dotnet publish.

这篇关于Azure 应用服务上的 500.31 ANCM 疑难解答的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！