VS 15.8.2 破坏了构建工具 - 缺少 RuntimeIdentifier答案

【问题标题】：VS 15.8.2 broke build tools - missing RuntimeIdentifierVS 15.8.2 破坏了构建工具 - 缺少 RuntimeIdentifier
【发布时间】：2019-02-10 10:10:14
【问题描述】：

最后一次 Windows 更新破坏了我们的整个构建链，我有点不知所措。

我有一个遗留项目，它是一个 VS 2017 dolution，包含大量项目（winform、基于 web 的情侣、仅一些 Webapi）。

在本地情况下一切正常。我可以建造它们。

在服务器上，proejct已经开始失败，错误是：

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>

到一些项目。不用找了。我很茫然，因为错误信息甚至没有告诉我是哪个项目。

【问题讨论】：

这里是相同的问题，相同的遗留项目，相同的 VS 版本。
TomTom - 你解决了吗？我现在也有同样的问题。
就像看起来一样消失了。请记住，我们现在是 15.8.6...

标签： visual-studio-2017 visual-studio-2017-build-tools

【解决方案1】：

在尝试构建之前的某个时间点，您需要删除 obj 文件夹。不止一个人展示了这个来解决问题。

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

【讨论】：

不。不是。我对整个文件夹树进行了核对 - 甚至必须在每次构建时都进行完整的 git 获取。没有构建。
在解决方案中删除我的每个项目中的 obj 文件夹为我消除了此错误。
我检查了一个新文件夹，仍然是同样的问题，现在开始发生这种情况，升级到 15.9.4，正常的 .net 框架 csproj。对我来说，这发生在使用 msbuild 的命令行上，visualstudio 构建良好。
我对 VS 15.9.9 也有同样的错误。该问题仅出现在 devenv 命令行中。不是通过 VS GUI。
未来参考，这可能是由于移动到 PackageReference 并返回，留下残留物。未解决的问题：github.com/dotnet/project-system/issues/3164

【解决方案2】：

虽然@Señor CMasMas 的回答过去对我有帮助，但我现在发现（因为安装了 .NET Core SDK v2.2 - 我不知道这是否相关）我还需要close and reopen Visual Studio .所以对我来说，秘诀是：

清洁解决方案
删除obj文件夹
Delete the .vs folder（可选，如果你得到红线但它构建正常）
关闭并重新打开 Visual Studio
然后构建

【讨论】：

我已将项目转换为新的 SDK 格式，构建它并回滚我的更改。然后我得到了 csproj 旧格式的 project file doesn't list 'win' as a "RuntimeIdentifier" 错误。我已经删除了所有在使用新项目格式时创建的 bin 和 obj 文件，并且它再次开始编译。

【解决方案3】：

将此：<RuntimeIdentifier>win</RuntimeIdentifier> 添加到您的项目文件中，例如在元素 TargetFrameworkVersion 之后。确保元素名称是单数的。 RuntimeIdentifiers 则用于新的 csproj 格式

【讨论】：

这对我有用。我正在混合 .Net Standard 和 .Net Framework 项目。这是所有 .Net Framework .csproj 文件从命令行构建解决方案所必需的。
在我将项目迁移到使用 PackageReference 样式 nuget 的情况下，这对我有用。
为什么它会在 Visual Studio 和命令行中的 msbuild 中构建.. 但在 azure 中中断？
我将复数版本 win-x64;win-x86 添加到一个 .NET 项目文件中，并且它起作用了。
这为我修复了构建。（我一直在尝试让构建在构建服务器上运行，包括调试构建、单元测试和 Coverlet 覆盖，并使用 Wix 安装程序和自定义操作发布构建 [它们是旧式 C# 项目]。）记得删除'修改 .csproj 文件后的 bin' 和 'obj' 文件。问题可能是因为解决方案有一个非标准的解决方案平台：“混合”。

【解决方案4】：

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

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

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

【讨论】：

简单有效。我只需要删除 bin 和 obj.... 非常感谢
不错。或者，rm *\obj -Recurse -Force 也可以使用

【解决方案5】：

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

关闭 Visual Studio（可能保留其他 Visual Studio 实例）
删除解决方案中所有项目中的所有 bin 和 obj 文件夹
重新打开解决方案并构建

注意如果bin文件夹存在，只删除obj文件夹是不行的，还需要删除bin文件夹。

【讨论】：

【解决方案6】：

我遇到了类似的问题。我的错误是

错误：您的项目文件未将“win10”列为 “运行时标识符”。您应该将“win10”添加到项目文件中的“RuntimeIdentifiers”属性，然后重新运行 NuGet 恢复。

好吧，事实证明我只需要将构建目标从“任何 CPU”更改为其他内容（例如 x64）...

【讨论】：

【解决方案7】：

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

【讨论】：

【解决方案8】：

我也有类似的情况。我尝试通过 msbuild 构建解决方案而不安装 Visual Studio 2017，只需安装最新版本的 vs 2017 构建工具。这是我的步骤：

dotnet 恢复 a.sln （这个解决方案中有一些 .Net 标准库项目，其他的是 .NET 4.7.2 项目）。
调用 msbuild.exe 来构建这个解决方案。
我收到“缺少 RuntimeIdentifier”的错误。

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

这似乎是旧版 Nuget 的问题。请参考here。最后，我通过使用最新 Nuget (v5.0.2) 的还原包解决了这个问题。步骤：

删除 obj 和 bin 文件夹
nuget.exe 恢复 a.sln
调用 msbuild.exe

【讨论】：

将 nuget.exe 从 v4.9.4.5839 升级到 v5.4.0.6315 为我解决了这个问题。

【解决方案9】：

我在切换 vstools 构建链（VS2017/VS2019）时遇到了同样的问题 - 这是为我解决的问题 - 通过rimraf 蛮力清理

您的项目文件未将“win”列为“运行时标识符”。您应该将“win”添加到项目文件中的“RuntimeIdentifiers”属性中，然后重新运行 NuGet 恢复

删除中间构建输出工件

rimraf *\obj\**

【讨论】：

【解决方案10】：

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

鉴于这似乎只是在本地构建，我会将本地计算机上的 .csproj 与构建服务器上的 .csproj 进行比较。有人告诉我，它们并不相同。

上述 Microsoft.NuGet.targets 文件中的 FWIW 第 186 行正在运行 ResolveNuGetPackageAssets 任务，您可以看到作为 NuGetRuntimeIdentifier 属性传递的 RuntimeIdentifier 参数。您可能可以在工作构建的诊断日志中回溯它以查看它是如何分配的。

但鉴于这适用于一个盒子，而不是另一个盒子，我只需检查您的项目文件并验证两个系统上的 RuntimeIdentifier 标记是否相同。

此致，

【讨论】：

【解决方案11】：

通过运行手动恢复包时，在使用 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，并将其设置为与 teamCity 中选定的构建工具对应的内容，在这种情况下：

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

（事实证明，teamCity 本身在自己的 NuGet 步骤中也受到此问题的困扰：How to set the MSBuild verision for TeamCity NuGet Installer?）

【讨论】：

【解决方案12】：

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

【讨论】：

【解决方案13】：

就我而言，这发生在 Azure 版本上。

我能够通过强制构建使用 Visual Studio 2019 工具来解决它。

我修改了我们的 build.cake 文件，以便 MSBuild 步骤包括 VS 2019 的 UseToolVersion，如下所示：

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

【讨论】：

【解决方案14】：

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

【讨论】：

【解决方案15】：

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

【讨论】：

【解决方案16】：

我收到与原始海报相同的错误，使用 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。这些项目使用 VS 2017 在本地构建良好，但在 TeamCity Enterprise 10.0.5 上构建时失败。我最近将我的项目从 .package 转换为 PackageReference - 这导致构建失败。

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

【讨论】：

【解决方案17】：

我总是在 Azure 管道中收到此错误。到目前为止，我注意到在各种场合为我解决了以下问题： 1. 不要提交 .suo 文件 - 如果是，请删除并重新提交 2. 不要提交 bin 或 obj 文件夹 - 如果是，请删除并重新提交 3.如果有新项目添加，在解决方案属性中设置项目依赖-保存并提交.sln文件

【讨论】：

【解决方案18】：

我升级到 VS 到 15.9.27 后，其中一个单元测试项目无法编译，并且删除 obj 文件夹的解决方案对我有用

【讨论】：

【解决方案19】：

调用 MSBuild 之前的简单 nuget 还原对我有用。我有针对 .NET Framework 4.7.2（不是 SDK 样式，旧样式）的项目，这些项目是从 packages.config 语法迁移而来的。

【讨论】：

【解决方案20】：

我在添加到 VS2015 和 VS2019 解决方案中的 MSBUILD 项目时遇到了这个问题，该项目是使用 VS2010 编译的。我只是将其从解决方案中排除，并使用 VS2010 将其编译，包括将 .DLL 文件添加到其他适用于 VS2015 和 VS2019 的项目中。

【讨论】：

【解决方案21】：

到项目多目标 fmk 将此添加到您的项目文件中，例如：

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

或

<PropertyGroup>
  <RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>

【讨论】：