blocks|key|2063586|text|在尝试构建之前的某个时刻，您需要删除obj文件夹。不止一个人展示了这一点来解决问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2063587|https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html|offset|length|2063588|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|3D|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

At some point before attempting to build, you need to delete the obj folder.
More than one person showed this to solve the problem.

<a href="https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html" rel="noreferrer">https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html</a>

blocks|key|4173857|text|RuntimeIdentifier应该看起来更像这里所描述的：https://docs.microsoft.com/en-us/dotnet/core/rid-catalog。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4173858|鉴于这似乎是构建只在本地查找，我会将本地计算机上的.csproj与构建服务器上的one进行比较。有种感觉告诉我，它们并不完全相同。|4173859|在上面提到的Microsoft.NuGet.targets文件中的第186行，FWIW正在运行ResolveNuGetPackageAssets任务，您可以看到RuntimeIdentifier参数作为NuGetRuntimeIdentifier属性传递。您可能会在您的工作构建的诊断日志中回溯它，以查看它是如何分配的。|4173860|但是考虑到这在一个机器上有效，而在另一个机器上不起作用，我只需要dbl检查您的项目文件，并验证两个系统上的RuntimeIdentifier标记是否相同。|4173861|由衷地，|4173862|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/dotnet/core/rid-catalog^0|V|1K|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]]]

The RuntimeIdentifier should look something more like what's described here: <a href="https://docs.microsoft.com/en-us/dotnet/core/rid-catalog" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/dotnet/core/rid-catalog</a>.

Given this appears to build just find locally, I'd diff the .csproj on your local machine against the one on your build server. Something tells me, they are not identical.

FWIW, Line 186 in the noted Microsoft.NuGet.targets file, is running the ResolveNuGetPackageAssets task, and you can see the RuntimeIdentifier argument being passed as the NuGetRuntimeIdentifier property. You could probably backtrace that in your working build's diagnostic log to see how it's being assigned.

But given this works on one box, and not on another, I'd just dbl check your project files and verify that the RuntimeIdentifier tag identical on both systems.

Sincerely,

blocks|key|2063661|text|对我来说，这就像用x86平台而不是ARM平台编译一个Windows+IoT应用程序一样简单。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2063662|entityMap^0|9|3|H|3|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

For me, it was as simple as compiling a Windows IoT App with <code>x86</code> platform instead of <code>ARM</code>.

blocks|key|1652149|text|尽管@Señor+CMasMas的回答在过去对我有帮助，但我现在发现(自从安装了.NET核心SDK+v2.2+-我不知道这是否相关)，我也需要close+and+reopen+Visual+Studio。所以对我来说，食谱是：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1652150|Visual+Studio+solution|1652151|Delete+folders|unordered-list-item|1652152|
|1652153|Delete+the+.vs+folder+(可选，如果出现红线但构建正常)|style|CODE|1652154|1652155|关闭并重新打开|1652156|1652157|，然后构建|1652158|1652159|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/50833577/1294318|1|https://stackoverflow.com/a/46599632/1294318^0|1Z|U|0|0|0|0|0|B|3|0|L|1|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1A|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|1B|8|@]|9|@]|C|$]]|$1|K|3|L|5|H|7|1C|8|@$A|1D|B|1E|M|N]]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|O|3|J|5|6|7|1I|8|@]|9|@]|C|$]]|$1|P|3|Q|5|H|7|1J|8|@]|9|@]|C|$]]|$1|R|3|J|5|6|7|1K|8|@]|9|@]|C|$]]|$1|S|3|T|5|H|7|1L|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]|$1|V|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]]|W|$X|$5|Y|Z|10|C|$11|12]]|13|$5|Y|Z|10|C|$11|14]]]]

Although @Señor CMasMas's answer has helped me in the past, I'm now finding (since installing the .NET Core SDK v2.2 - I don't know if that's related though) that I also need to <a href="https://stackoverflow.com/a/50833577/1294318">close and reopen Visual Studio</a>. So for me the recipe is:
<ul>
<li>Clean solution</li>
<li>Delete <code>obj</code> folders</li>
<li><a href="https://stackoverflow.com/a/46599632/1294318">Delete the <code>.vs</code> folder</a> (optional, if you get red lines but it builds OK)</li>
<li>Close and reopen Visual Studio</li>
<li>Then build</li>
</ul>

blocks|key|2063737|text|在项目文件中添加这个：<RuntimeIdentifier>win</RuntimeIdentifier>，例如在元素TargetFrameworkVersion之后。确保元素名称是单数的。另一方面，RuntimeIdentifiers在新的csproj格式中使用|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2063738|entityMap^0|B|16|1N|M|2S|I|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

Add this: <code>&lt;RuntimeIdentifier&gt;win&lt;/RuntimeIdentifier&gt;
</code> to your project file, for example after element <code>TargetFrameworkVersion</code>. Make sure the element name is singular. <code>RuntimeIdentifiers</code> on the other hand is used in the new csproj format

blocks|key|2063800|text|我也有类似的情况。我尝试在不安装Visual+Studio+2017的情况下通过msbuild构建解决方案，只需安装最新版本的vs+2017构建工具。以下是我的步骤：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2063801|2063802|dotnet+restore+a.sln+(此解决方案中有一些.Net标准库项目，其他项目是用于构建此解决方案的.NET+4.7.2+projects).|ordered-list-item|2063803|call+msbuild.exe。我得到的错误是"missing+RuntimeIdentifier".|2063804|“|2063805|unordered-list-item|2063806|2063807|2063808|您的项目文件没有将'win‘列为"RuntimeIdentifier“。您应该在项目文件的"RuntimeIdentifiers“属性中添加”win“，然后重新运行NuGet+restore。|blockquote|2063809|2063810|2063811|这似乎是旧版Nuget中的一个问题。请参考here。最后，我通过使用最新的Nuget+(v5.0.2)的恢复包解决了这个问题。具体步骤如下：|offset|length|2063812|删除obj和bin+folders|2063813|nuget.exe+|2063814|+a.sln|2063815|call+msbuild.exe|2063816|2063817|2063818|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/NuGet/Home/issues/2553^0|0|0|0|0|0|0|0|0|0|0|0|L|4|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1G|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1H|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1I|8|@]|9|@]|A|$]]|$1|J|3|-4|5|K|7|1J|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1M|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1P|8|@]|9|@$U|1Q|V|1R|1|1S]]|A|$]]|$1|W|3|X|5|6|7|1T|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|K|7|1U|8|@]|9|@]|A|$]]|$1|10|3|11|5|E|7|1V|8|@]|9|@]|A|$]]|$1|12|3|13|5|E|7|1W|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]]]

I have a similar case. I try to build a solution via msbuild without installing Visual Studio 2017, just install the latest version of vs 2017 build tools. Here are my steps: 

<ol>
<li>dotnet restore a.sln
(There are some .Net Standard Library project in this solution, the others are .NET 4.7.2 projects).</li>
<li>call msbuild.exe to build this solution. </li>
<li>I got the error of "missing RuntimeIdentifier".</li>
</ol>

<blockquote>
 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.
</blockquote>

It seems an issue in the old version of Nuget. Please refer <a href="https://github.com/NuGet/Home/issues/2553" rel="nofollow noreferrer">here</a>. Finally, I resolved it via restore packages with the latest Nuget (v5.0.2).
the steps:

<ol>
<li>Delete obj and bin folders</li>
<li>nuget.exe restore a.sln</li>
<li>call msbuild.exe</li>
</ol>

blocks|key|2063871|text|在我的例子中，这是在Azure构建上发生的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2063872|我能够通过强制构建使用Visual+Studio+2019工具来解决这个问题。|2063873|我修改了我们的build.cake文件，以便MSBuild步骤包含VS+2019的UseToolVersion，如下所示：|offset|length|style|BOLD|2063874|+++++MSBuild(_solutionFile,+settings+=>+settings.SetConfiguration(_configuration)
+++++++++.UseToolVersion(MSBuildToolVersion.VS2019));|code-block|syntax|javascript|2063875|entityMap^0|0|0|7|A|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|V|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

In my case, this was happening on an Azure build. 

I was able to resolve it by forcing the build to use Visual Studio 2019 tools.

I modified our build.cake file so that the MSBuild steps included the UseToolVersion for VS 2019 like this:

<pre><code> MSBuild(_solutionFile, settings =&gt; settings.SetConfiguration(_configuration)
 .UseToolVersion(MSBuildToolVersion.VS2019));
</code></pre>

blocks|key|1649011|text|或者，您可以只在项目的根目录中运行您应该以管理员身份运行的PowerShell中的脚本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649012|Get-ChildItem+.\+-include+bin,obj+-Recurse+%7C+foreach+{+remove-item+$_.fullname+-Force+-Recurse+}|code-block|syntax|javascript|1649013|此脚本将删除所有obj和bin文件夹|1649014|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Or you just can run in the root directory of your project the script in PowerShell that you should run as administrator.

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

this script will delete all obj and bin folders

blocks|key|2063955|text|我也遇到过类似的问题。我的错误是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2063956|2063957|错误:您的项目文件未将'win10‘列为"RuntimeIdentifier“。您应该在项目文件的"RuntimeIdentifiers“属性中添加”win10“，然后重新运行NuGet+restore。|blockquote|2063958|2063959|2063960|嗯，原来我只需要把构建目标从“任何CPU”改成其他的(比如x64)……|2063961|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|K|$]]

I had a similar problem. My error was

<blockquote>
 error : Your project file doesn't list 'win10' as a
 "RuntimeIdentifier". You should add 'win10' to the
 "RuntimeIdentifiers" property in your project file and then re-run
 NuGet restore.
</blockquote>

Well, it turned out I just had to change by build target from "Any CPU" to something else (x64 for example)...

blocks|key|2064002|text|对我来说唯一有效的方法是删除所有项目文件，然后从版本控制中重新下载它们。然后问题就消失了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2064003|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The only thing that worked for me was to delete ALL project files and download them again from the version control. Then the problem disappeared.

blocks|key|5591900|text|如果您的目标是Azure+Service+Fabric或其他64位环境，请检查在CSPROJ文件中定义的所有配置中是否具有一致的<PlatformTarget>x64</PlatformTarget>。在我的例子中，它在本地构建得很好，但在CI服务器上构建失败了，因为许多配置中有一个配置有<PlatformTarget>AnyCPU</PlatformTarget>。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5591901|entityMap^0|1S|10|41|13|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

If you are targeting Azure Service Fabric or other 64-bit environment, check that you have a consistent <code>&lt;PlatformTarget&gt;x64&lt;/PlatformTarget&gt;</code> in all configurations defined in the CSPROJ file. In my case it built just fine locally but failed on the CI server because one of the many configurations had <code>&lt;PlatformTarget&gt;AnyCPU&lt;/PlatformTarget&gt;</code>.

blocks|key|2064073|text|您必须找出解决方案中的哪些项目触发了此错误。如果您查看error面板，您可以找到这一点。转到该项目的位置并删除bin和obj文件夹。然后重建。应该没问题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2064074|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

you got to figure out which projects in your solution trigger this error. you can find this if you look at the error panel. 
go to that projects locations and delete both the bin and the obj folders. 
then rebuild. 
should be alright

blocks|key|1652371|text|我收到了与原始海报相同的错误，Msbuild+v15.9.21|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1652372|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|code-block|syntax|javascript|1652373|我的项目是.net框架v4.6.2。这些项目使用VS+2017在本地构建得很好，但在TeamCity企业版10.0.5上构建失败。我最近将我的项目从.package转换为PackageReference+-这导致构建失败。|1652374|我的解决方案是添加一个新的构建步骤，以便在构建解决方案之前显式地恢复解决方案的nuget包。似乎在将项目转换为PackageReference之前，这是在构建步骤中隐式完成的。|1652375|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I was receiving the same error as the original poster, with Msbuild v15.9.21

<pre><code>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
</code></pre>

My projects are .net Framework v4.6.2. The projects build fine locally using VS 2017, but failed when building on TeamCity Enterprise 10.0.5. I had recently converted my projects from .package to PackageReference - this causing the build to fail.

My solution was to add a new build step to explictly restore the solution's nuget packages before building the solution. It seems that before converting the projects to PackageReference this was being done on the build step implicitly.

blocks|key|5592023|text|我总是在Azure管道中得到这个错误。到目前为止，我在各种情况下注意到了以下修复:+1.不提交.suo文件-如果是，请删除并重新提交2.不要提交bin或obj文件夹-如果是，请删除并重新提交3.如果添加了新项目，请在解决方案属性上设置项目依赖项-保存并提交.sln文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5592024|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I always get this error in the Azure pipeline. So far I have noticed the following fixed for me in various occasions:
1. do not commit the .suo file - if so, delete and recommit
2. do not commit the bin or obj folders - if so, delete and recommit
3. if there is a new project added, set the project dependency on the solution properties - save and commit the .sln file

blocks|key|5592079|text|我在vstools构建链(VS2017/VS2019)之间切换时也遇到了同样的问题--这是我解决这个问题的方法--通过rimraf进行暴力清除|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5592080|5592081|您的项目文件没有将'win‘列为"RuntimeIdentifier“。您应该将'win‘添加到项目文件中的"RuntimeIdentifiers“正确类型中，然后重新运行NuGet+restore|blockquote|5592082|5592083|5592084|删除中间构建输出工件|5592085|rimraf+*\obj\**|5592086|entityMap^0|1N|6|0|0|0|0|0|0|0|F|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|U|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|V|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|W|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|X|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|Y|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|Q|$]]

I had this same issue toggling across vstools build chains (VS2017/VS2019) - here is what fixed it for me - brute force clean via <code>rimraf</code>

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

<h3>Remove Intermediary Build Output Artifacts</h3>

<code>rimraf *\obj\**</code>

blocks|key|1652460|text|在我升级到VS到15.9.27之后，我遇到了同样的问题，其中一个单元测试项目无法编译，删除obj文件夹的解决方案对我有效|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1652461|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I had same issue with one of the unit test project failing to compile after I upgraded to VS to 15.9.27 and the solution to delete the obj folder worked for me

blocks|key|4174543|text|在调用MSBuild之前，一个简单的nuget恢复对我有效。我有一些项目是从packages.config语法移植过来的，目标是.NET+Framework4.7.2(不是SDK风格，传统风格)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4174544|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

A simple nuget restore before calling MSBuild worked for me. I have projects targeting .NET Framework 4.7.2 (not SDK Style, legacy style) which I migrated from packages.config syntax.

blocks|key|5592161|text|我在Vs+2019+(16.8.6)中遇到了同样的错误，以下步骤解决了我的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5592162|5592163|关闭visual+studio+(可以保留其他visual+studio实例)|ordered-list-item|5592164|删除solution|5592165|Reopen解决方案中所有项目中的所有bin和obj文件夹，然后生成|offset|length|style|BOLD|5592166|<>G211|5592167|请注意，如果bin文件夹存在，则只删除obj文件夹不起作用，您还需要删除bin文件夹。|5592168|entityMap^0|0|0|0|0|J|3|N|3|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|X|8|@$J|Y|K|Z|L|M]|$J|10|K|11|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|S|$]]

I have come across same error in Vs 2019 (16.8.6), following steps resolved my problem.
<ol>
<li>Close visual studio (other visual studio instances may remain)</li>
<li>Delete all bin and obj folders in all projects in the solution</li>
<li>Reopen solution and Build</li>
</ol>
Note that if bin folders exist, deleting only obj folders doesn't work, you need to delete bin folders too.

blocks|key|1649232|text|在通过运行以下命令手动恢复包时，在使用packageReference的项目中遇到此问题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649233|NuGet.exe+restore+my.sln|code-block|syntax|javascript|1649234|作为TeamCity构建的一部分(因此可能与nf313743的答案https://stackoverflow.com/a/60951212/128384相关)，然后使用msbuild构建项目。当msbuild开始处理PackageReference时，这将导致以下错误：|offset|length|1649235|[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.|1649236|删除obj目录等在这里不起作用，因为它们是通过restore步骤添加的；添加RuntimeIdentifier可能会，但在VS2017命令行上构建完全相同的目录效果很好，所以很明显，区别在于TeamCity设置环境的方式。|style|CODE|1649237|罪魁祸首可以在第一个调用的输出中找到：|1649238|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'.|1649239|它使用VS2019安装中的msbuild，而项目是由VS2017构建的，所以在它们混合的某个地方有一种不兼容性，这并不是意外的。无论如何，关键是TeamCity不会像VS2017命令行那样设置一个完整的环境，NuGet文档中说|1649240|By+default+the+MSBuild+in+your+path+is+picked,
otherwise+it+defaults+to+the+highest+installed+version+of+MSBuild.|1649241|这就是它使用VS2019+one的原因。解决方案是手动将-MsBuildPath传递给NuGet，并将其设置为与teamCity中选定的buildtools相对应的内容，在本例中：|1649242|NuGet.exe+-msBuildPath+"%25MSBuildTools15.0_x86_Path%25"+restore+my.sln|1649243|(事实证明，teamCity本身在它自己的NuGet步骤：How+to+set+the+MSBuild+verision+for+TeamCity+NuGet+Installer?中也受到了这个问题的困扰)|1649244|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/60951212/128384|1|https://stackoverflow.com/questions/44522321/how-to-set-the-msbuild-verision-for-teamcity-nuget-installer^0|0|0|X|17|0|0|0|N|7|0|0|0|0|0|S|C|0|0|T|1P|1|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1F|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1G|8|@]|9|@$I|1H|J|1I|1|1J]]|A|$]]|$1|K|3|L|5|D|7|1K|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|1L|8|@$I|1M|J|1N|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1O|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1R|8|@]|9|@]|A|$E|F]]|$1|Y|3|Z|5|6|7|1S|8|@$I|1T|J|1U|O|P]]|9|@]|A|$]]|$1|10|3|11|5|D|7|1V|8|@]|9|@]|A|$E|F]]|$1|12|3|13|5|6|7|1W|8|@]|9|@$I|1X|J|1Y|1|1Z]]|A|$]]|$1|14|3|-4|5|6|7|20|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]|1C|$5|17|18|19|A|$1A|1D]]]]

Had this problem in projects using packageReference when manually restoring packages by running
<pre><code>NuGet.exe restore my.sln
</code></pre>
as part of a TeamCity build (so might be related nf313743's answer <a href="https://stackoverflow.com/a/60951212/128384">https://stackoverflow.com/a/60951212/128384</a>) and then building projects using msbuild.
This would result in the following error when msbuild begins dealing with the PackageReference:
<pre><code>[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 &quot;RuntimeIdentifier&quot;. You should add 'win-x86' to the &quot;RuntimeIdentifiers&quot; property in your project file and then re-run NuGet restore.
</code></pre>
Deleting obj directories etc doesn't work here because they get added by the <code>restore</code> step; adding a RuntimeIdentifier might, but building the exact same on a VS2017 commandline works fine so clearly the difference is in how TeamCity sets up the environment.
The culprit could be found in the output of the first call:
<pre><code>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'.
</code></pre>
it uses msbuild from the VS2019 installation whereas the project is being built by VS2017, so somewhere in mixing those there is an incompatibility which is not unexpected. Anyway, the key is likely that TeamCity doesn't setup a complete environment like the VS2017 commandline does and the NuGet documentation says
<pre><code>By default the MSBuild in your path is picked,
otherwise it defaults to the highest installed version of MSBuild.
</code></pre>
so that's why it uses the VS2019 one. Solution is to manually pass <code>-MsBuildPath</code> to NuGet and set it to what corresponds to the selected buildtools in teamCity, in this case:
<pre><code>NuGet.exe -msBuildPath &quot;%MSBuildTools15.0_x86_Path%&quot; restore my.sln
</code></pre>
(and it turns out teamCity itself is also plagued by this in its own NuGet step: <a href="https://stackoverflow.com/questions/44522321/how-to-set-the-msbuild-verision-for-teamcity-nuget-installer">How to set the MSBuild verision for TeamCity NuGet Installer?</a>)

blocks|key|1649249|text|我在一个MSBUILD项目中遇到了这个问题，这个项目是用VS2010编译的，我已经将它添加到了VS2015和VS2019的解决方案中。我只是将它从解决方案中排除，并使用VS2010编译它，将.DLL文件包含到其他使用VS2015和VS2019的项目中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649250|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I experienced this issue with a MSBUILD project that I've added into a solution of VS2015 and VS2019, that project was compiled with VS2010. I just excluded it from solution and compiled it with VS2010, including the .DLL file into other projects that work with VS2015 and VS2019.

blocks|key|1649262|text|对于多目标fmk项目，将其添加到您的项目文件中，例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649263|<PropertyGroup>
++<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
</PropertyGroup>|code-block|syntax|javascript|1649264|或|1649265|<PropertyGroup>
++<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>|1649266|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

To projects mult-target fmk
Add this to your project file, for example:
<pre><code>&lt;PropertyGroup&gt;
 &lt;RuntimeIdentifier&gt;ubuntu.16.04-x64&lt;/RuntimeIdentifier&gt;
&lt;/PropertyGroup&gt;
</code></pre>
or
<pre><code>&lt;PropertyGroup&gt;
 &lt;RuntimeIdentifier&gt;win&lt;/RuntimeIdentifier&gt;
&lt;/PropertyGroup&gt;
</code></pre>

The last windows update has broken our whole build chain and I am a little at a loss at what causes it.

I have a legacy project that is a VS 2017 dolution with a significant number of projects (winform, couple web based, some Webapi only).

Locally things work perfectly. I can just build them.

On the server, the proejct has started to fail, and the error is:

<pre><code>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'.
</code></pre>

I have added 

<pre><code>&lt;RuntimeIdentifiers&gt;win&lt;/RuntimeIdentifiers&gt;
</code></pre>

To a number of projects. No change. I am at a loss, because the error message does not even tell me which project.

VS 15.8.2 broke build tools - missing RuntimeIdentifier

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

上一次的windows更新破坏了我们的整个构建链，我对它的原因感到有点不知所措。我有一个遗留项目，这是一个VS 2017解决方案，有大量的项目(winform，基于web的夫妇，一些Webapi )。在本地，事情运行得很完美。我可以直接构建它们。在服务器上，proejct已经开始失败，错误是：C:\Program Fi...

问VS 15.8.2 broke构建工具-缺少RuntimeIdentifier
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问VS 15.8.2 broke构建工具-缺少RuntimeIdentifierEN