时间戳

首页 > 解决方案 > ASP.NET Core - 生成的 web.config 中的 processPath 错误

asp.net-core - ASP.NET Core - 生成的 web.config 中的 processPath 错误

问题描述

我有一个很奇怪的问题。

我们正在开发的其中一个应用程序在发布到 Azure Web App 后停止工作。在本地一切正常。经过长时间的调查，罪魁祸首是构建（在 VSTFS 中）生成的 web.config 有这个：

<aspNetCore processPath=".\SomeServiceName.Api " stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

而正确的是： <aspNetCore processPath=".\SomeServiceName.Api.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

请注意缺少的 .exe。

项目的构建输出设置为控制台应用程序。它是 ASP.NET Core 应用程序，在完整框架上运行。构建使用Visual Studio BuildVSTS 中的任务运行，具有以下 MSBuildArguments：

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)"

如果我在我的开发机器上运行构建，使用 MSBuild cli，使用相同的命令行参数，我会得到：

<aspNetCore processPath="dotnet" arguments=".\SomeServiceName.Api.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

该项目正在使用<Project Sdk="Microsoft.NET.Sdk.Web">.

我猜我可以将 web.config 添加到项目中（它现在根本不存在）并以我想要的方式将其置于源代码控制中，这应该可以解决我的部署中断问题。但我想知道：

  1. 在 VSTS 上构建生成的 web.config 显然是错误的。这是 Microsoft.NET.SDK.Web 中的错误吗？
  2. 我无权访问实际的构建服务器。我猜唯一合理的解释是有人更新了.net core SDK，这就是行为改变的原因。这有意义吗？msbuild 目标是来自 .NET Core SDK，还是 Visual Studio 的一部分？
  3. 我在我的机器上得到了不同的 web.config。这是为什么？

更新：对于任何在这里绊倒的人，这里 是
github 上的问题链接： https
://github.com/aspnet/websdk/issues/408虽然发布周期）。

标签： asp.net-coremsbuild

解决方案

我有完全相同的问题，我上周解决了它。我们有 2 个 ASP.Net Core 项目，一个显示问题，另一个没有问题。所以我们比较了 2 个 .csproj 文件。

事实证明，在我们的例子中，我们需要做的就是删除

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
  <PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>

.csproj 的属性；完成后，MSBuild 正确创建了 web.config，包括 processPath 末尾的 .exe。

推荐阅读