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.

Just disappeared as it seems. Remember we are now at 15.8.6... — TomTom, Oct 04 '18 at 15:09

score 342 · Answer 1 · answered Sep 06 '18 at 21:48

342

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

answered Sep 06 '18 at 21:48

Señor CMasMas

4,290
2
14
21

4

Nope. Not it. I nuke the whole folder tree - even has to make a full git get on every build. No build. – TomTom Sep 07 '18 at 02:03
45

Deleting the obj folder in each of my projects in the solution removed this error for me. – Adrian Sanguineti Sep 09 '18 at 13:13
1

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. – neslekkiM Dec 12 '18 at 12:07
7

I also have the same error with VS 15.9.9. The problem appear only with devenv command line. Not through the VS GUI. – David Mar 15 '19 at 12:46
4

fur future reference, this can happen due to moving to PackageReference and back, leaving residues. open issue: https://github.com/dotnet/project-system/issues/3164 – Daniel Dror Apr 07 '19 at 08:02
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. – Colm Bhandal Sep 17 '19 at 10:25
2

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. – RosieC Oct 09 '19 at 14:03
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? – Piotr Kula Mar 30 '20 at 22:17
`dotnet clean` helped me. I believe it removes the obj folder – tolache Oct 29 '20 at 15:58
2

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. – TJ Rockefeller May 03 '22 at 15:19
Clean _obj_ and _bin_ sometimes helps when work in Rider. But for some cases have to delete and checkout git repo – lyolikaa Jul 07 '23 at 07:44

score 73 · Answer 2 · edited Feb 22 '21 at 09:43

73

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

edited Feb 22 '21 at 09:43

peterh

11,875
18
85
108

answered Mar 06 '19 at 02:40

OutstandingBill

2,614
26
38

7

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. – oleksa Jun 04 '19 at 09:55
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](https://git-scm.com/docs/git-clean) would be an option to remove the intermediate build results. – tobster Apr 12 '22 at 06:58
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. – Simon Elms Oct 28 '22 at 03:46
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! – ryancdotnet Jun 30 '23 at 17:09

score 58 · Answer 3 · answered Mar 28 '19 at 20:41

58

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

answered Mar 28 '19 at 20:41

Bahaa

1,577
18
31

7

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. – Russell Phillips May 16 '19 at 01:36
4

This worked for me in a case where I had migrated the project to use PackageReference style nuget. – RosieC Oct 09 '19 at 14:04
5

Why does it then build in visual studio and from msbuild in command line.. but breaks in azure? – Piotr Kula Mar 30 '20 at 22:17
5

I added the plural version win-x64;win-x86 to a .NET project file, and it worked. – Rye bread Dec 02 '20 at 12:17
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'. – Mike Rosoft Feb 16 '21 at 15:20
1

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. – The Senator Nov 20 '22 at 16:08

score 27 · Answer 4 · edited Oct 18 '19 at 05:53

27

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

edited Oct 18 '19 at 05:53

Nick Cox

6,164
2
24
30

answered Sep 24 '19 at 12:34

llotall

555
5
11

Simple and effective. I just needed to remove `bin` and `obj`.... Thanks very much – Andre Soares Oct 25 '19 at 14:01
5

Nice. Alternatively, `rm *\obj -Recurse -Force` also works – Subjective Reality Dec 17 '19 at 21:25
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`. – w5l Aug 24 '23 at 09:14

score 19 · Answer 5 · answered Feb 24 '21 at 19:41

19

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

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

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

answered Feb 24 '21 at 19:41

ozanmut

2,898
26
22

Unloading the failing project before deleting it's \bin & \obj worked for me. – Kevin S. Miller May 02 '23 at 21:08

score 7 · Answer 6 · answered Jul 22 '21 at 15:27

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://stackoverflow.com/a/60951212/128384) 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?)

@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). — Christoph, Aug 03 '22 at 12:08

score 6 · Answer 7 · answered Oct 20 '19 at 10:37

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

Icewindq Liu · Answer 8 · 2019-06-05T12:37:21.143

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:

dotnet restore a.sln (There are some .Net Standard Library project in this solution, the others are .NET 4.7.2 projects).
call msbuild.exe to build this solution.
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:

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

Upgrading nuget.exe from v4.9.4.5839 to v5.4.0.6315 solved this problem for me. — blaz, Apr 09 '20 at 12:14

score 5 · Answer 9 · answered Feb 26 '20 at 10:47

5

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

answered Feb 26 '20 at 10:47

eva

89
1
2

score 3 · Answer 10 · answered May 14 '20 at 22:05

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\**

score 1 · Answer 11 · answered Sep 07 '18 at 05:06

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,

score 1 · Answer 12 · answered Mar 31 '20 at 13:02

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.

score 1 · Answer 13 · answered Dec 08 '21 at 21:12

1

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>

answered Dec 08 '21 at 21:12

Lucio Pelinson

430
5
7

Newey · Answer 14 · 2022-11-07T19:52:53.683

1

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.

edited Nov 07 '22 at 19:52

answered Apr 08 '22 at 18:31

Newey

123
2
8

which tag? RuntimeIdentifier? – CervEd Aug 02 '22 at 09:33
1

Yes we had multiple RuntimeIdentifier tags with the same values. – Newey Aug 02 '22 at 17:15
1

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 – Newey Aug 02 '22 at 17:48
You may surround the tag with backticks ` which will appropriately format as well as add emphasis – CervEd Aug 03 '22 at 08:15

score 0 · Answer 15 · answered Dec 17 '18 at 20:27

0

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

answered Dec 17 '18 at 20:27

Dane Bouchie

421
5
11

score 0 · Answer 16 · answered Aug 30 '19 at 14:21

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));

score 0 · Answer 17 · answered Nov 27 '19 at 13:12

0

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.

answered Nov 27 '19 at 13:12

Martin Dimitrov

818
10
19

score 0 · Answer 18 · answered Dec 05 '19 at 18:22

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

score 0 · Answer 19 · answered Apr 01 '20 at 22:34

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

score 0 · Answer 20 · answered Sep 25 '20 at 16:14

0

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

answered Sep 25 '20 at 16:14

user76713

1

score 0 · Answer 21 · answered Nov 03 '20 at 22:23

0

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.

answered Nov 03 '20 at 22:23

Nikhil

3,304
1
25
42

score 0 · Answer 22 · answered Dec 03 '21 at 03: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.

score 0 · Answer 23 · answered Jul 15 '22 at 15:32

0

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.

answered Jul 15 '22 at 15:32

Grault

974
12
31

score 0 · Answer 24 · answered Apr 03 '23 at 20:46

0

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.

answered Apr 03 '23 at 20:46

Andrew Heumann

1

VS 15.8.2 broke build tools - missing RuntimeIdentifier

24 Answers24

Remove Intermediary Build Output Artifacts