最后一次Windows更新打破了我们的整个构建链，而导致它的原因我有点不知所措。
我有一个旧项目，它是VS 2017解决方案，其中包含大量项目（winform，基于web的夫妇，仅某些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>
到许多项目。不用找了。我很茫然，因为错误消息甚至都没有告诉我哪个项目。
答案 0 :(得分：48)
在尝试构建之前的某个时候，您需要删除obj文件夹。 有一个以上的人表示可以解决此问题。
答案 1 :(得分：7)
尽管@SeñorCMasMas的回答过去对我有所帮助，但我现在发现（因为安装了.NET Core SDK v2.2-如果不相关，则不知道），我也需要close and reopen Visual Studio。所以对我来说，食谱是：
obj文件夹.vs folder（可选，如果出现红线，但显示正常）答案 2 :(得分：5)
您必须弄清楚解决方案中的哪些项目会触发此错误。如果您查看错误面板，则可以找到此内容。 转到该项目位置，然后删除bin和obj文件夹。 然后重建。 应该没事
答案 3 :(得分：4)
或者您也可以在项目的根目录中运行应以管理员身份运行的PowerShell中的脚本。
Get-ChildItem .\ -include bin,obj -Recurse | foreach { remove-item $_.fullname -Force -Recurse }
此脚本将删除所有obj和bin文件夹
答案 4 :(得分：2)
我在 Vs 2019 (16.8.6) 中遇到了同样的错误，以下步骤解决了我的问题。
注意，如果bin文件夹存在，只删除obj文件夹是不行的，你还需要删除bin文件夹。
答案 5 :(得分：2)
在项目文件中添加以下内容：<RuntimeIdentifier>win</RuntimeIdentifier>
，例如在元素TargetFrameworkVersion之后。确保元素名称为单数。另一方面，RuntimeIdentifiers用于新的csproj格式
答案 6 :(得分：1)
我有类似的情况。我尝试通过msbuild构建解决方案而不安装Visual Studio 2017，仅安装vs 2017构建工具的最新版本。这是我的步骤：
您的项目文件未将“ win”列为“ RuntimeIdentifier”。您应该在项目文件的“ RuntimeIdentifiers”属性中添加“ win”，然后重新运行NuGet还原。
在旧版本的Nuget中，这似乎是一个问题。请参阅here。最后，我通过使用最新的Nuget（v5.0.2）的还原包解决了该问题。 步骤：
答案 7 :(得分：1)
我在切换vstools构建链（VS2017 / VS2019）时遇到了同样的问题-这是为我解决的问题-通过rimraf进行蛮力清理
您的项目文件未将“ win”列为“ RuntimeIdentifier”。您应该在项目文件的“ RuntimeIdentifiers”属性中添加“ win”，然后重新运行NuGet restore
rimraf *\obj\**
答案 8 :(得分：0)
对我唯一有效的方法是删除所有项目文件，然后从版本控件中再次下载它们。然后问题消失了。
答案 9 :(得分：0)
在通过运行手动恢复包时使用 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?）
答案 10 :(得分：0)
在调用MSBuild之前，一个简单的nuget恢复对我有用。我有一些针对.NET Framework 4.7.2（不是SDK样式，不是传统样式）的项目，这些项目是我从package.config语法中迁移过来的。
答案 11 :(得分：0)
在升级到VS至15.9.27以及删除obj文件夹的解决方案对我有用之后，我遇到了一个问题，其中一个单元测试项目无法编译
答案 12 :(得分：0)
我总是在Azure管道中收到此错误。到目前为止，我已经在各种情况下为我解决了以下问题： 1.不要提交.suo文件-如果是，请删除并重新提交 2.不要提交bin或obj文件夹-如果是这样，请删除并重新提交 3.如果添加了新项目，请在解决方案属性上设置项目依赖性-保存并提交.sln文件
答案 13 :(得分：0)
我使用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之前，这是在构建步骤上隐式完成的。
答案 14 :(得分：0)
如果目标是Azure Service Fabric或其他64位环境，请检查CSPROJ文件中定义的所有配置中的<PlatformTarget>x64</PlatformTarget>是否一致。就我而言，它在本地构建得很好，但是在CI服务器上失败了，因为许多配置之一具有<PlatformTarget>AnyCPU</PlatformTarget>。
答案 15 :(得分：0)
我有类似的问题。我的错误是
错误：您的项目文件未将“ win10”列为 “ RuntimeIdentifier”。您应该将“ win10”添加到 项目文件中的“ RuntimeIdentifiers”属性，然后重新运行 NuGet恢复。
好吧，事实证明，我只需要按构建目标将“任何CPU”更改为其他内容（例如x64）...
答案 16 :(得分：0)
就我而言，这是在Azure构建上发生的。
我能够通过强制构建使用Visual Studio 2019工具来解决此问题。
我修改了我们的 build.cake 文件，以便MSBuild步骤包括如下所示的VS 2019的UseToolVersion：
MSBuild(_solutionFile, settings => settings.SetConfiguration(_configuration)
.UseToolVersion(MSBuildToolVersion.VS2019));
答案 17 :(得分：0)
对我来说，这就像使用x86平台而不是ARM平台编译Windows IoT App一样简单。
答案 18 :(得分：0)
RuntimeIdentifier应该看起来更像这里描述的内容：https://docs.microsoft.com/en-us/dotnet/core/rid-catalog。
鉴于这似乎只是在本地查找而已，所以我将本地计算机上的.csproj与构建服务器上的.csproj进行比较。有人告诉我，它们并不相同。
FWIW，提到的Microsoft.NuGet.targets文件中的第186行正在运行ResolveNuGetPackageAssets任务，并且您可以看到RuntimeIdentifier参数作为NuGetRuntimeIdentifier属性传递。您可能可以在工作版本的诊断日志中回溯该行，以查看其分配方式。
但是考虑到这可以在一个盒子上工作，而不能在另一个盒子上工作，我只是dbl检查您的项目文件并验证RuntimeIdentifier标记在两个系统上是否相同。
此致