VS 15.8.2 broke build tools - missing RuntimeIdentifier

Question

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 solution 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:

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'.

I have added

<RuntimeIdentifiers>win</RuntimeIdentifiers>

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

Plaque

Identical issue here, same legacy project, same VS version. – Bologna

TomTom - did you solve it? I have the same problem now. – Basle

Just disappeared as it seems. Remember we are now at 15.8.6... – Plaque

This is not limited to VS2017, happens with VS2022 also. – Geminate

Yea. You may want to realize when I wrote that post ;) But you are right - that is an ongoing issue to some degree. – Plaque

Answer 1

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

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

Groundmass

Nope. Not it. I nuke the whole folder tree - even has to make a full git get on every build. No build. – Plaque

Deleting the obj folder in each of my projects in the solution removed this error for me. – Knowling

I checked out to an new folder, still same problem, this started to happen now, after upgrading to 15.9.4, normal .net framework csproj. For me this happens on commandline using msbuild, visualstudio builds fine. – Rottenstone

I also have the same error with VS 15.9.9. The problem appear only with devenv command line. Not through the VS GUI. – Curule

fur future reference, this can happen due to moving to PackageReference and back, leaving residues. open issue: github.com/dotnet/project-system/issues/3164 – Pokpoke

We have a .sln file template checked into Git. Whenever we add a new project to our solution, we must locally delete out .sln and replace it with the template contents. Then we must configure to our local needs. It seems like when this happens, some of obj folders go out of sync somehow (check sums?) with the solution file. So deleting obj (which seems like some sort of cache) as Adrian mentioned for all offending projects has worked for me every time so far. For this particular case. – Jacelynjacenta

This worked for me in one case, when I had updated a project to the new SDK format, then switched to a branch in git that did not have that updated format. Deleting the obj folder after switching branch fixed it. However I have another project that has been migrated to use PackageReference and I get the same error when building the migrated project. Deleting the obj doesn't help in this second case. – Salas

I have had some similar issue in upgrading a project to package refernce.. but the error happens in Axure Enterpise build. Locally it build fine.. I even copied the build command from azure.. ran it locally.. and locally OK.. in Azure NOT OK.. so annoying? – Bustup

dotnet clean helped me. I believe it removes the obj folder – Premonitory

I ran into this issue when I upgraded a .NET framework style project to the new SDK style project format, but I had to do work on a different branch that didn't have the project updated. I thought "clean" was supposed to delete stuff in bin and obj, but manually deleting the obj folder is what ultimately fixed things. – Bertabertasi

Clean obj and bin sometimes helps when work in Rider. But for some cases have to delete and checkout git repo – Ostrich

Answer 2

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 close and reopen Visual Studio. So for me the recipe is:

• Clean solution
• Delete obj folders
• Delete the .vs folder (optional, if you get red lines but it builds OK)
• Close and reopen Visual Studio
• Then build

Tripitaka

I've converted project to the new SDK format, built it and rolled back my changes. Then I've got this project file doesn't list 'win' as a "RuntimeIdentifier" error for csproj legacy format. I've removed all bin and obj files that had been created while playing with new project format and it started to compile again. – Glennaglennie

Thanks, this should be the accepted answer for any project that is about to be recompiled but not changed in any way. In a git repo the use of git-clean would be an option to remove the intermediate build results. – Piedadpiedmont

This is what worked for me. I had tried deleting the obj folder of the project that wasn't building, then tried cleaning the solution and deleting both the bin and obj folders of that project. It was only when I followed these instructions, including closing and reopening VS, that I was able to build successfully. This was in Visual Studio 2022, build 17.3.5, by the way. – Previse

After attempting to "upgrade" a .NET Framework 4.8 project to the new SDK style, and finding out the hard way that it breaks things like ClickOnce, etc from .NET Framework days, I manually rolled back to the original MSBuild XML format. That's when I started getting build errors, saying "Your project file doesn't list 'win' as a "Runtimeidentifier"". By performing the actions above, nuking the .vs/obj/bin folders, and closing/reopening all VS instances, it started building again. Thank you! – Dangle

Answer 3

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

Philips

This worked for me. I'm mixing .Net Standard and .Net Framework projects. This was required for all the .Net Framework .csproj files to for the solution to build from command line. – Haswell

This worked for me in a case where I had migrated the project to use PackageReference style nuget. – Salas

Why does it then build in visual studio and from msbuild in command line.. but breaks in azure? – Bustup

I added the plural version <RuntimeIdentifiers>win-x64;win-x86</RuntimeIdentifiers> to a .NET project file, and it worked. – Breban

This fixed the build for me. (I have been trying to get the build to work on build server, with debug build, unit tests and Coverlet coverage, and release build with Wix installer and custom actions [which are old-style C# projects].) Remember to delete the 'bin' and 'obj' files after modifying the .csproj files. The problem may have been because the solution had a non-standard solution platform: 'Mixed'. – Meemeece

I added the singular as above for a mixture of .net standard and .net 6 assemblies with a .net framework on the windows latest agent in Azure Devops. Fixed for me. Many thanks. – Naylor

Answer 4

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

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

this script will delete all obj and bin folders

Loricate

Simple and effective. I just needed to remove bin and obj.... Thanks very much – Risinger

Nice. Alternatively, rm *\obj -Recurse -Force also works – Robins

Careful that this solution deletes all bin and obj folders. If you have a node_modules folder inside your tree, note than some modules (ie @babel, @eslint and probably many others) contain bin folders as well. Deleting all bin might fix your dotnet build but will then break your npm build. – Gunwale

Just add -Exclude node_modules – Loricate

Answer 5

I have come across same error in Vs 2019 (16.8.6), following steps resolved my problem.

1. Close visual studio (other visual studio instances may remain)
2. Delete all bin and obj folders in all projects in the solution
3. Reopen solution and Build

Note that if bin folders exist, deleting only obj folders doesn't work, you need to delete bin folders too.

Tomato

Unloading the failing project before deleting it's \bin & \obj worked for me. – Pinchas

Answer 6

Had this problem in projects using packageReference when manually restoring packages by running

NuGet.exe restore my.sln

as part of a TeamCity build (so might be related nf313743's answer https://mcmap.net/q/125493/-vs-15-8-2-broke-build-tools-missing-runtimeidentifier) and then building projects using msbuild. This would result in the following error when msbuild begins dealing with the 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.

Deleting obj directories etc doesn't work here because they get added by the restore 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:

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'.

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

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

so that's why it uses the VS2019 one. Solution is to manually pass -MsBuildPath to NuGet and set it to what corresponds to the selected buildtools in teamCity, in this case:

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

(and it turns out teamCity itself is also plagued by this in its own NuGet step: How to set the MSBuild verision for TeamCity NuGet Installer?)

Mammillate

@stjin: You are my hero! In my multi-targeting solution containing net48/net5.0-windows combined projects as well as net48 only projects - one of them a not updateable non-SDK project - this was the only thing that worked for my Azure pipeline: To use NUGET RESTORE instead of DOTNET RESTORE and specify the -MSBuildPath (which must point to the folder where MSBuild.exe resides, not to the exe itself). – Stereoscope

Answer 7

I had a similar problem. My error was

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.

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

Pertussis

Answer 8

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:

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

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.

It seems an issue in the old version of Nuget. Please refer here. Finally, I resolved it via restore packages with the latest Nuget (v5.0.2). the steps:

1. Delete obj and bin folders
2. nuget.exe restore a.sln
3. call msbuild.exe

Anceline

Upgrading nuget.exe from v4.9.4.5839 to v5.4.0.6315 solved this problem for me. – Perdure

Answer 9

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

Benadryl

Answer 10

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

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

Remove Intermediary Build Output Artifacts

rimraf *\obj\**

Vacuum

Answer 11

The RuntimeIdentifier should look something more like what's described here: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog.

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,

Defense

Answer 12

I was receiving the same error as the original poster, with 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

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.

Nucleon

Answer 13

To projects mult-target fmk Add this to your project file, for example:

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

or

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

Aggarwal

Answer 14

So I was seeing the same error message as this on our on premises DevOps build server, but it built fine locally in Visual Studio as well as via the msbuild on the command line.

I checked and I DID have the <RuntimeIdentifiers> defined in my project file and clearing out the obj and bin folders on the server did NOT fix it for me.

Our issue was we had the < RunTimeIdentifiers> tag showing up MULTIPLE times in the build section,(probably from a bad merge at some point in the past). After removing the duplicate tags, DevOps successfully built the project.

I was googling for hours and never stumbled on this being the cause of the issue for anyone else. Hopefully this saves someone else some time in the future if they have the same problem.

Rundell

which tag? RuntimeIdentifier? – Ferric

Yes we had multiple RuntimeIdentifier tags with the same values. – Rundell

Apologies I did originally did not add an extra space to the Tags in my respons above so markdown was trying to interpret them and it hid them so you couldn't see them in my original post – Rundell

You may surround the tag with backticks ` which will appropriately format as well as add emphasis – Ferric

Answer 15

Remove all obj folders from your solution by running the following command line script, then try a full rebuild:

for /d /r "C:\Your\Directory\Path" %d in (obj) do @if exist "%d" rmdir /s /q "%d"

Stillborn

Answer 16

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

Participation

Answer 17

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:

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

Tower

Answer 18

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.

Diaspora

Answer 19

If you are targeting Azure Service Fabric or other 64-bit environment, check that you have a consistent <PlatformTarget>x64</PlatformTarget> 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 <PlatformTarget>AnyCPU</PlatformTarget>.

Resinous

Answer 20

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

Affected

Answer 21

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

Joanajoane

Answer 22

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.

Jos

Answer 23

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.

Golfer

Answer 24

I'm using VS 2019 (16.11.17). I was working in 2022 on a different branch.

I tried all of these solutions and none worked, until I deleted the solution folder and cloned fresh.

Pullulate

Answer 25

For me, the secret was buried in a github issue: I had two .csproj files in the same directory, which is apparently discouraged. Moving one out to a different folder resolved the issue.

Graniteware