VS15.8.2中断构建工具-缺少 RuntimeIdentifier

最近的 Windows 更新打破了我们的整个构建链，我有点不知道是什么原因造成的。

我有一个遗留的项目，是一个 VS 2017解决方案与大量的项目(winform，夫妇基于网络，一些 Webapi 只)。

当地的东西都很好用，我可以自己造。

在服务器上，项目已经开始失败，错误是:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.


C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.


C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.


Process 'msbuild.exe' exited with code '1'.

我加了

<RuntimeIdentifiers>win</RuntimeIdentifiers>

很多项目。没有变化。我不知所措，因为错误消息甚至没有告诉我是哪个项目。

84715 次浏览
小开

在尝试生成之前，您需要删除 obj 文件夹。 不止一个人展示这个来解决问题。

Https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html

小开

RuntimeIdentifier 应该看起来更像这里描述的: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog。

鉴于这似乎只是构建在本地的 find，我将区分。您本地机器上的 csproj 与构建服务器上的 csproj 对比。直觉告诉我，他们不是完全一样的。

FWIW，Microsoft.NuGet.target 文件中的第186行，正在运行 ResolveNuGetPackageAsset 任务，您可以看到 RuntimeIdentifier 参数作为 NuGetRuntimeIdentifier 属性传递。您可以在您的工作构建的诊断日志中反向跟踪它，以查看它是如何分配的。

但是考虑到这种方法只能在一个机器上使用，而不能在另一个机器上使用，我只需要 dbl 检查您的项目文件，并验证 RuntimeIdentifier 标记在两个系统上是否相同。

真诚的,

小开

对我来说，这就像用 x86平台而不是 ARM编译一个 Windows 物联网应用程序一样简单。

小开

虽然@Se ñor CMasMas 的回答在过去对我有所帮助，但我现在发现(自从安装了。NET 核心 SDK v2.2-我不知道这是否相关，但) ，我也需要 关闭并重新打开 VisualStudio。所以对我来说，秘诀就是:

  • 干净的溶液
  • 删除 obj文件夹
  • 删除 .vs文件夹 (可选，如果得到红线但构建正常)
  • 关闭并重新打开 VisualStudio
  • 然后构建
小开

添加: < code > < RuntimeIdentifier > win 到您的项目文件，例如在元素 TargetFrameworkVersion之后。确保元素名称是单数。另一方面，RuntimeIdentifiers在新的 csproj 格式中使用

小开

我有个类似的案子。我尝试在不安装 VisualStudio2017的情况下通过 msbuild 构建解决方案，只需安装最新版本的 vs2017构建工具即可。以下是我的步骤:

  1. 网络恢复系统 (这个解决方案中有一些.NET 标准库项目，其他的是.NET 4.7.2项目)。
  2. 调用 msbuild.exe 来构建此解决方案。
  3. 我得到了“丢失 RuntimeIdentifier”的错误。

您的项目文件没有将“ win”列为“ RuntimeIdentifier”。您应该将“ win”添加到项目文件中的“ RuntimeIdentifier”属性中，然后重新运行 NuGet 恢复。

这似乎是旧版 Nuget 的一个问题。请参阅 给你。最后，我使用最新的 Nuget (v5.0.2)通过恢复包解决了这个问题。 步骤:

  1. 删除 obj 和 bin 文件夹
  2. Nuget.exe 恢复 a.sln
  3. 打电话给 msbuild.exe
小开

在我的例子中，这是在 Azure 构建中发生的。

我能够通过强制构建使用 VisualStudio2019工具来解决这个问题。

我修改了我们的 建造，蛋糕文件，以便 MSBuild 步骤包含 UseToolVersion for VS 2019，如下所示:

     MSBuild(_solutionFile, settings => settings.SetConfiguration(_configuration)
.UseToolVersion(MSBuildToolVersion.VS2019));
小开

或者，您只需在项目的根目录中运行 PowerShell 中的脚本，以管理员身份运行该脚本即可。

Get-ChildItem .\ -include bin,obj -Recurse | foreach { remove-item $_.fullname -Force -Recurse }

此脚本将删除所有 obj 和 bin 文件夹

小开

我也有过类似的问题，我的错误是

错误: 您的项目文件没有将“ win10”列为 “ RuntimeIdentifier”。您应该将“ win10”添加到 “ RuntimeIdentifier”属性，然后重新运行 NuGet 恢复。

好吧，结果是我只需要通过构建目标从“任意 CPU”改为其他的(例如 x64) ..。

小开

对我来说唯一有效的方法就是删除所有的项目文件，然后从版本控制中再次下载它们。然后问题就消失了。

小开

如果您的目标是 Azure Service Fabric 或其他64位环境，请检查在 CSPROJ 文件中定义的 所有配置中是否有一致的 <PlatformTarget>x64</PlatformTarget>。在我的例子中，它在本地构建得很好，但是在 CI 服务器上失败了，因为许多配置中有一个配置具有 <PlatformTarget>AnyCPU</PlatformTarget>。

小开

您必须弄清楚解决方案中的哪些项目会触发此错误。你可以找到这个，如果你看看错误面板。 转到该项目位置并删除 bin 和 obj 文件夹。 然后重建。 应该没事

小开

我收到了与原始海报相同的错误，使用 MSbuild v15.9.21

Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore

我的项目是。Net Framework v4.6.2.这些项目使用 VS2017在本地构建得很好，但是在 TeamCity Enterprise 10.0.5上构建时失败了。我最近把我的项目从。包到 PackageReference-这会导致构建失败。

我的解决方案是添加一个新的构建步骤，以便在构建解决方案之前显式地恢复解决方案的 nuget 包。在将项目转换为 PackageReference 之前，这似乎是在构建步骤中隐式完成的。

小开

在 Azure 管道中我总是遇到这个错误。到目前为止，我已经注意到，在各种场合下，下面的内容对我来说都是固定的: 不要提交.suo 文件-如果是这样，删除并重新提交 不要提交 bin 或 obj 文件夹-如果是这样，删除并重新提交 3.如果添加了新项目，请在解决方案属性上设置项目依赖项-保存并提交。档案

小开

我有同样的问题切换跨 vstools 建立链(VS2017/VS2019)-这里是什么为我修复它-蛮力干净通过 rimraf

您的项目文件没有将“ win”列为“ RuntimeIdentifier”。您应该将“ win”添加到项目文件中的“ RuntimeIdentifier”属性 ty 中，然后重新运行 NuGet 恢复

删除中间生成输出工件

rimraf *\obj\**

小开

在我升级到 VS 到15.9.27并且删除 obj 文件夹的解决方案对我起作用之后，我遇到了一个单元测试项目编译失败的同样问题

小开

在调用 MSBuild 之前的一个简单的 nuget 恢复对我来说很有用。我有目标项目。NET Framework 4.7.2(不是 SDK 样式，是遗留样式) ，我从 packages.config 语法迁移过来的。

小开

我在 VS 2019(16.8.6)中遇到了同样的错误，下面的步骤解决了我的问题。

  1. 关闭视觉工作室(其他视觉工作室实例可能保留)
  2. 删除解决方案中所有项目中的所有 垃圾箱和 对不起文件夹
  3. 重新打开解决方案并生成

请注意，如果 bin 文件夹存在，只删除 obj 文件夹不起作用，您也需要删除 bin 文件夹。

小开

在使用 packageReference 的项目中，在通过运行

NuGet.exe restore my.sln

作为 TeamCity 构建的一部分(可能与 nf313743的答案 https://stackoverflow.com/a/60951212/128384有关) ，然后使用 msbuild 构建项目。 当 msbuild 开始处理 PackageReference 时，这将导致以下错误:

[ResolveNuGetPackageAssets] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186, 5):
Your project file doesn't list 'win-x86' as a "RuntimeIdentifier". You should add 'win-x86' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

删除 obj 目录等在这里不起作用，因为它们是通过 restore步骤添加的; 添加一个 RuntimeIdentifier 可能会起作用，但是在 VS2017命令行上构建完全相同的目录可以很好地工作，所以很明显，不同之处在于 TeamCity 如何设置环境。

罪魁祸首可以在第一个调用的输出中找到:

NuGet.exe restore my.sln -NonInteractive
MSBuild auto-detection: using msbuild version '16.10.2.30804'
from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin'.

它使用 VS2019安装中的 msbuild，而项目是由 VS2017构建的，所以在混合这两者的某个地方存在不兼容性，这是意料之中的。无论如何，关键是 TeamCity 可能没有像 VS2017命令行那样设置一个完整的环境，NuGet 文档说

By default the MSBuild in your path is picked,
otherwise it defaults to the highest installed version of MSBuild.

这就是为什么它使用 VS2019的原因。解决方案是手动将 -MsBuildPath传递给 NuGet，并将其设置为与 Team City 中选定的 buildtools 相对应，在这种情况下:

NuGet.exe -msBuildPath "%MSBuildTools15.0_x86_Path%" restore my.sln

(事实证明，在 NuGet 的步骤 如何设置 TeamCity NuGet 安装程序的 MSBuild 版本？中，Team City 本身也受到了这个问题的困扰。)

小开

我在一个 MSUILD 项目中遇到了这个问题，我把它添加到了 VS2015和 VS2019的解决方案中，该项目是用 VS2010编译的。我只是从解决方案中排除了它，并用 VS2010编译了它，包括。DLL 文件到其他项目与 VS2015和 VS2019工作。

小开

多目标 fmk 项目 将其添加到项目文件中，例如:

<PropertyGroup>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
</PropertyGroup>

或者

<PropertyGroup>
<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>
小开

所以我在我们的开发服务器上看到了相同的错误消息，但是它在 Visual Studio 中本地构建得很好，并且通过命令行上的 msbuild。

我检查，我确实有 <RuntimeIdentifiers>定义在我的项目文件和清除了 obj 和 bin 文件夹在服务器上没有为我修复它。

我们的问题是我们在构建部分中多次显示了 < RunTimeIdentifier > 标记(可能是因为过去某个时候的错误合并)。在删除重复的标记之后，DevOps 成功地构建了该项目。

我在谷歌上搜索了好几个小时，从来没有偶然发现这是其他任何人的问题的原因。如果将来有人遇到同样的问题，希望这能为他们节省一些时间。

小开

我使用的是 VS 2019(16.11.17) ，我在2022年在另一个分支工作。

我尝试了所有这些解决方案，但没有一个奏效，直到我删除了解决方案文件夹并重新克隆了解决方案。


提交答案