When load my .NET Frameowrk 4.6.2 solution in Visual Studio 2017, it gives me the following warning:
Severity Code Description Project File Line Suppression State
Warning Your project is not referencing the ".NETFramework,Version=v4.6.2" framework. Add a reference to ".NETFramework,Version=v4.6.2" in the "frameworks" section of your project.json, and then re-run NuGet restore.
Another:
Warning IDE0006 Error encountered while loading the project. Some project features, such as full solution analysis for the failed project and projects that depend on it, have been disabled. BigData 1 Active
However, loading in visual studio 2015 is totally fine with the exactly same solution files and structures.
Why is this and how I can solve it?
BTW, from what I read, in the latest updates, project.json is merged back to .csproj, why here it's still recommending something on project.json
I had this show up as an error when building shortly after migrating a solution from vs2015 to 2017, and then also doing some git restructuring. As it turns out, I think git was actually the culprit.
Regardless, manually deleting the bin & obj folders in the affected projects solved it for me. (Clean alone wasn't cutting it.)
Are you sure, you installed all needed packages for your project? It could be a not installed feature. Go in the launcher to modify and check, are there all dependencies installed?
Related
I have a WebApplication which contains reference to WCF services.
While building using Visual Studio 2010, Build fails without any error or warning. However building the .csproj using MsBuild is successful.
Can't figure out what should I try in Visual Studio, to resolve / diagnose the issue. Can you please help out?
I find out that the build has been failing,
From text displayed in status Bar.
From output window:
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
The output tab includes configuration details.
------ Build started: Project: <projectName here> Configuration: Debug Any CPU
I noticed that if "Build + Intellisense" is selected in the Error List, it causes the error messages to be swallowed.
Change this option to "Build Only", and all error messages will be displayed:
I don't know if this is a bug in Visual Studio or what, but it certainly revealed hidden error messages that were the key to pinpointing the failure for me.
Some, like Richard J Foster, have suggested increasing the "MSBuild project build output verbosity" setting to "Diagnostic" (the highest possible option), but this didn't solve the problem for me, as Visual Studio appeared to be suppressing the error message(s) themselves.
As an alternative, you may try to use the raw output messages from the "Output" tab, which haven't been filtered by Visual Studio. Either do an in-place search for the strings "error" and/or "failed", or copy all of the output to your favorite text editor and do a search there.
To ensure that the Output window appears each time you do a build, you can go to Tools → Options → Projects and Solutions → General, and ensure that the option "Show Output Window when build starts" is checked.
As an additional troubleshooting step, it is also possible to build the project from the PowerShell command line by running dotnet build. This will show you the complete build output, including any errors that Visual Studio may be hiding.
I just ran into a similar situation. In my case, a custom action (from the MSBuildVersioning package available on Nuget.org - http://www.nuget.org/packages/MSBuildVersioning/) which appeared in the csproj file's BeforeBuild target was failing without triggering any error message in the normal place.
I was able to determine this by setting the "MSBuild project build output verbosity" (in the latest Visual Studio's Tools tab [Path: Tools > Options > Build and Run]) to "Diagnostic" as shown below. This then showed that the custom action (in my case HgVersionFile) was what had failed.
Here are some things that you can try:
If your solution contains more than one project, try building each project one at a time. (You may even want to try opening each project independently of the solution.)
If applicable, ensure that all of your projects (including dependencies and tests) target the same version of the .NET Framework. (Thanks to user764754 for this suggestion!)
Tip: Check Tools → Extension and Updates to ensure that your packages are up-to-date.
Ensure that all dependency projects are built to target the same platform as your main project.
Try restarting Visual Studio.
As suggested by Bill Yang, try running Visual Studio as Administrator, if you aren't already. (If you are already running Visual Studio as Administrator, perhaps try the opposite?)
Try restarting your computer.
Try "Rebuild All".
Run "Clean Solution", then remove your *vspscc* and *vssscc* files, restart Visual Studio, and then "Rebuild All".
As suggested by Andy, close Visual Studio, delete the .suo file, and restart Visual Studio.
As suggested by Arun Prasad E S, close Visual Studio, delete the .vs folder in your solution directory, and then re-open Visual Studio. (This folder is auto-generated by Visual Studio and contains cache, configuration settings, and more. More details can be found in these questions: Visual Studio - Deleting .vs folder and https://stackoverflow.com/q/48897191.)
As suggested by MrMalith, close Visual Studio, delete the obj folder in your solution directory, clear your temporary folder, and then re-open Visual Studio.
Delete the hidden .vs folder & restart Visual Studio. That worked for me.
I want to expand on Sasse's answer. I had to target the correct version of .NET to resolve the problem.
One project was giving me an error:
"The type or namespace name 'SomeNamespace' does not exist in the namespace 'BeforeSomeNamespace' (are you missing an assembly reference?)".
There was no error in the Error List window but the assembly had a yellow warning sign under "References".
I then saw that the referencing project targeted 4.5.1 and the referenced project 4.6.1. Changing 4.6.1 to 4.5.1 allowed the overall build to succeed.
Nothing was working for me so I deleted the .suo file, restarted VS, cleaned the projected, and then the build would work.
I tried many things like restarting Visual Studio, cleaning and rebuilding the solution, restarting the PC, etc., but none of them worked for me. I was finally able to solve the problem by doing the following:
First of all, make sure all the projects in your solution (including tests) are targeting the same .NET version. Then:
Save pending changes in the project and close Visual Studio
Find the exact location from file explorer and find "obj" file and open it,
Then, delete all the included files (some files won't remove, it doesn't matter, just skip them).
Use run command (by pressing Windows Key + R) and type "%temp%" and press enter to find temporary files.
Finally, delete them all.
On other possibility is that Visual Studio needs to run as Administrator, this might be related to deploying to local IIS server or other deployment need.
Just for the sake of completion and maybe helping someone encountering the same error again in the future, I was using Mahapps metro interface and changed the XAML of one window, but forgot to change the partial class in the code-behind. In that case, the build failed without an error or warning, and I was able to find it out by increasing the verbosity of the output from the settings:
In my case (VS 2019 v16.11.20), disabling Text Editor->C#->Advanced->Enable 'pull' diagnostics in the options solved the issue.
Double check for _underscore.aspx pages in your project.
I had a page and code-behind:
`myPage.aspx` and `myPage.aspx.vb`
when building the project, I'd get errors on the .aspx.vb page stating that properties defined on the .aspx page didn't exist, even though the page itself would build fine and there were NO OTHER ERRORS showing in the output (even with diagnostic level build output).
I then came across a page in the project that was named the same thing but with an underscore: _myPage.aspx - not sure where it came from, I deleted it, and the solution built fine.
At the start I'd like to note that I've spent some time researching this issue and suggested solutions for similar questions like this one didn't help me.
Problem background
I need to migrate a Firebreath plugin project (which I haven't worked on previously) from PC_1 to PC_2.
As far as I'm aware the project was started on PC_1 on Visual Studio 2010 and later moved to Visual Studio 2013 Pro. There's one solution consisting of 19 projects. I have an instruction which says that in order to get the plugin installer I should first Build project_x and after that Build project_y_WiXInstall. Both steps work without any issues on this machine.
Then there's PC_2 which had Visual Studio 2015 Community installed before I started working on it. I've removed it, installed Visual Studio 2013 Pro (version 12.0.21005.1 REL - exactly the same as on PC_1), moved all of the needed files and I'm trying to get rid of all of the compilation errors. So far I figured out I had to install Cmake 2.8, Windows Driver Toolkit 7.1 and manually override an incorrect VCTargetsPath MSBuild variable
Problem description
Currently when I try to compile the project on the new machine I get these two errors (this is an image link since I can't embed images yet on this account). I'm not sure what's going on with the first error message since it looks incomplete and the file CUSTOMBUILD doesn't exist, but I'm not bothered by it too much since the previous compilation error I fixed also had a similar "artifact" as the first error and it disappeared after fixing the second one.
The covered part of the second error message is the project path. The error origin (Microsoft.Cpp.Platform.targets file, line 64) looks like this:
<!-- Error out if toolset does not exists in Visual Studio 2010 or 2012 -->
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_CurrentPlatformToolsetShortName);$(PlatformToolset)" Condition="'$(ToolsetTargetsFound)' != 'true'" />
What didn't help
The error description suggests using an Upgrade Solution... option, but there's no such thing when I right-click the solution
As an accepted answer for the question I've posted at the start of my post suggests, I've checked the Properties of all 19 of my projects (including the project ZERO_CHECK) but their Platform Toolset is already set to Visual Studio 2013 (v120).
I've also tried changing the Platform Toolset to inherit from parent or project defaults for all of the projects. This resulted in it switching to Visual Studio 2010 (v100) (not installed) and after that I've right-clicked on the projects and chose Upgrade VC++ compiler and libraries. After this the Platform Toolset was back to the Visual Studio 2013 (v120) but it didn't help with the compilation error.
As a NON-accepted answer for the question I've posted at the start of my post suggests, I've tried searching for all of the occurrences of 10.0 and V100 in all of my .vcxproj files to replace them but I haven't found any occurrences of them.
[EDIT]
I just got an idea to try building the project with MSBuild from the command line. There's a bit more info compared to errors inside Visual Studio, so maybe it will help with resolving the issue: https://pastebin.com/JhN3dXM3
So the thing you're missing here is that FireBreath projects are built using CMake -- the actual contents of the build directory should always be completely temporary and never stored in source control. To build the project on a new computer you need to run the prep command again from scratch.
If the previous maintainer changed the build files manually and/or migrated it to a newer version of visual studio without using cmake to do it then they did some very ugly things and all bets are off... good luck.
This is why all the firebreath documentation (I wrote most of it) strongly urges that the build directory be transient and you always do project file updates in cmake.
Hope that helps!
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.
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
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
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
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
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.
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?)
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
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)...
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
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\**
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,
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.
For me, it was as simple as compiling a Windows IoT App with x86 platform instead of ARM.
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));
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.
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>.
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.
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
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
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.
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.
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>
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.
I wanted to tinker this open source remake of the famous Claw.
Visit https://github.com/pjasicek/OpenClaw
Before I start with how I've cloned this game and tried to build it, I'm new to the open source community. I did the following things.
I cloned the repository.
Opened the project using Visual Studio 2017 Community edition and I changed the Configuration to Release and platform to Win32.
I then built the libwap solution without any errors.
Then I used CMake 3.11.0 to generate the required files for the Box2D solution and then generated it and then the Box2D build was a success.
I built the Midiproc manually and finally, I tried building the entire solution.
It threw a MSVCR120D.dll missing error and I copied all the .dlls from the game's release folder https://github.com/pjasicek/OpenClaw/releases
Now the game runs just fine when I launch it from the File explorer, but when I try to launch it from Visual Studio 2017, it throws the following error.
Check out this image:
How do I run the game from Visual Studio? Have I misconfigured the Visual Studio?
If you need any more details on what I did, please let me know.
[EDIT] I want to configure Visual Studio to be able to run the release and modify the source code so I can tinker it and try to understand how the game works internally.
I cloned the repository again and did a clean compilation of all the solutions. Turns out there was a problem when I copied/overwritten all dlls from the release build. Now, the game builds and executes fine.
Thanks for the help.
When I try to view the properties dialog of any project VS2017 spits out a bunch of errors.
"An error occurred while loading the rule set file 'C:/Program
Files(x86)\Microsoft Visual Studio\2017\Community\Team Tools\Static Analysis
Tools\Rule Sets\AllRules.ruleset'."
..\BasicCorrectnessRules.ruleset'.
..\DesignGuidelinesRules.ruleset'.
..\ExtendedCorrectnessRules.ruleset'.
..\ExtendedDesignGuidelinesRules.ruleset.'
..\GlobalizationRules.ruleset'.
..\ManagedMinimumRules.ruleset'.
..\MinimumRecommendedRules.ruleset'.
..\MixedMinimumRules.ruleset'.
..\MixedReccommendedRules.ruleset'.
..\NativeMinimumRules.ruleset'.
..\NativeReccommendedRules.ruleset'.
..\SecurityRules.ruleset'.
I don't know why this started happening, I didn't change anything in the install directory. All of those files are there in the directory, not sure why they are causing errors. Anyone know the cause?
Bottom line: I had the same problem. I had to do a repair install of Visual Studio 2017 to make this work properly. I tried just upgrading to Version 15.4.5 (from 15.4.4), but it didn't resolve the problem.
The problem didn't track the solution being used. I have two computers - one worked with the solution, the other failed with identical files. I copied the 'rules' files from the working computer to the failed one - no joy. On the working computer, I updated VS successfully (to 15.4.5), but on the failing computer I couldn't get the update to work (see Visual studio 2017 installer won't run after extracting). Once I resolved the problem noted in the other link and updated to 15.4.5, I still had to do a 'repair install' (from Add/Remove Programs) to completely resolve the problem.