I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
Related
This morning I upgraded to VS 2017 15.3 and now am getting yellow triangles for most of my references. The project runs fine (build is good in CLI and VS and restore has been run multiple times) that I can tell (and even better on dotnetcore 2.0 actually) but these remain. Has anyone else had this happen or have a suggestion? Thanks.
Link to project.assets.json file --> https://www.dropbox.com/s/c85yuyjiu4pnget/project.assets?dl=0
Also issue of greyed out usings and red references although everything builds and runs fine.
Update: VisualStudio twitter account responded to me to note that this is a bug and they are working on a fix for the future on this....
I have two responses to my post:
1) The using issue noted with things greyed out was actually a ReSharper issue. If you upgrade to VS 2017 15.3 and use R# make sure you update it as well to 2017.2.
2) The Yellow triangles issue is being looked at by the Visual Studio team but honestly I believe it to be linked to warnings in the build that those references are being coerced to either lower dependencies (ie Newtonsoft at different levels) or previews. The quickly evolving .NET 2.0 world may have exacerbated this issue. Yellow triangles have traditionally meant missing but check your warnings to see if that is related and then review the dependency chain. I will update this answer once I hear back from VS team (shout out to them and Damian Edwards + Scott Hanselman for helping me with this on Twitter).
I was experiencing the yellow triangle on references issue after updating the projects in my (.NET 4.6.1) solution to the new .NET Standard .csproj format that comes with VS2017. The references I was getting warnings for were ProjectReference type (although it seemed to spill over into PackageReference for common packages in the projects in question).
I did not have any build warnings and there was nothing in the verbose build output to indicate what the cause could be.
I could follow all warnings back to a single project in my solution. I was able to solve by removing that project from my solution and then adding it back and re-adding only the necessary project references.
It seems the issue was related to unnecessary project references (or possibly circular) caused by the new transitive dependencies support. After removing the project and adding it back with only the minimum ProjectReferences and relying on transitive dependencies support to propagate the dependency, the warnings all disappeared.
This also solved an issue where the project in question was failing compilation during a command line msbuild initiated build on my CI server which only has VS2017 build tools installed (not the full IDE).
I had the same issue, some of the references were marked with the yellow triangle. However, I was able to build and run my project.
I managed to remove these warning by following steps from this answer:
.Net 2015 References with yellow triangle for Nuget packages on portable libraries
I turned on tracing for Visual Studio, I had next warnings in log files for all uncorrectly loaded references:
Encountered conflict between 'Reference:Microsoft.Win32.Primitives, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll'. Choosing 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
To be precise, I did next steps:
Removed error condition from my .csproj file
Removed <Private>true</Private> parameter for not-loaded references in .csproj file
Deleted not-loaded packages from \lib and \ref folders in corresponding MSBuild folder.
Deleted packages from \packages folder in solution.
Restored nuget packages.
I'm not sure all these steps are necessary, but it worked for me.
You could check my answer on relative topic here: https://stackoverflow.com/a/59704420/7969733
Just for documentation purpose for new person with this issue try
this and you will rememberme :D
If you go to: Tools > NuGet Administrator > Configurations. and you
have "Allow nuget...." and "automatically check...." cheked.
The only thing than you have to do is click con the button "Clear
All NuGet Cache(s)"
That's it, you don't have to edit manual thinks than can be dangerous,
believe me, I use to need to done some of the steps than describe here
a lot of time, and try more than 5 steps of the official Microsoft
documentation for that issue you could check it here:
https://learn.microsoft.com/nuget/consume-packages/package-restore#restore-packages-automatically-using-visual-studio
But just cleaning the cache solve all the problems
To "Clear All NuGet Cache(s)" in Visual Studio 2019
Tools->NuGet Package Manager->Package Manager Setting
Mismatched Windows SDK Version between the referencing project and the references will cause it. In the vcxproj file it is "<WindowsTargetPlatformVersion>SDK Version</WindowsTargetPlatformVersion>"
I was upgrading from VS2012 to VS2017. Everything was good, then I upgraded to a new version of libtomcrypt and libtommath. Rather than tweak my existing projects, I up-converted the projects from the distributions from VS2008 -> VS2012 -> VS2017. In the process, I picked up Windows SDK Version 10.0.17763.0 in both the new projects. However, all of the projects that referenced those were 8.1, and thus the warning.
I know that this was ready to solve it, and one of my answers was ready to say something about that, but, maybe some of you present the same error and none of this solution listed here solves the problem... I don't know why this problem comes with the global installation of .net 6, but, if you present this issue again, you need to go to
C:\Users\YourUsername.nuget
And delete all the content, don't be afraid, that's a cache generator than will be created again if is need it.
I had a similar issue with visual studio 2017. And discovered that, if when I changed the dependency settings of the package I wanted to install (from lowest dependency to highest) everything worked fine.
Today faced the same issue with an imported project.
FAILED ATTEMPTS: Tried updating nougat packages, checking improper imports and everything imaginable. No help.
SOLUTION: At last just tried building the solution and it worked!
PS: Try building the project first. If it does not work then go for solution hunting.
We are currently evaluating the new Visual Studio 2015 and encountered a strange problem with IntelliSense. When I compiled our main solution with the new studio the build succeeds, but nevertheless 6 errors are shown.
I discovered that it's not a real error, but only an intellisense error. The code is definitely correct and everything compiled successfully. The code however is marked red and errors show up in the error list.
All 6 errors have the same origin. It's a simple constructor call. Strange enough, but there are also some occurrences of the exact same constructor without any errors.
The error message:
Code: CS1729
Message: '<the class>' does not contain a constructor that takes that many arguments.
Project: <the project name>
File: <the path to the file>
The new studio was installed on a freshly installed Windows 7 without any legacy software (no VS13).
I've already tried to clear the caches, deleted the suo file, deleted bin and obj directories, cleaned and rebuilt the solution etc. But nothing worked.
Can anyone explain that behavior to me?
I had thousands of intellisense errors and 0 build errors. After deleting .suo file and restarting VS intellisense errors are gone.
Suo file is located relatively to source in:
.vs\SolutionName\v14\.suo
According to comment: Beware that *.suo is a hidden file.
Edit: According to comments, VS2017 has the same issue, so you can use similar solution: Delete .vs\SolutionName\v15\.suo
VS2019 still has this issue. Delete .vs\SolutionName\v17\.suo
If deleting .suo still does solve your problem, then delete also all bin and obj directories in every project in the solution.
Also had this problem with a migrated project, so I referenced the Microsoft.CSharp dll. In some projects I needed to remove and add again the Reference in the project.
Ran into similar issue in Visual Studio 2017 ASP.Net Core Project. Following steps did the trick for me
Perform Clean Solution
Close VS
Delete .suo file & Delete bin/obj directories
Reopen VS
Similar problem as others, but different resolution. Posting in case I can help someone else.
Running Visual Studio 2017 15.5.2. I use Git and frequently switch branches. Several weeks ago, I started having editors show me errors (all related to types it could not find even though references were valid). Compile worked great. I confirmed the same issue in VS 2017 15.6 Preview (Jan 6, 2018). I would try to delete cache, SUO files, or bin/obj folders and no impact. At first it would appear to work. Reopen Visual Studio and everything would look good. Use "Rebuild Solution" and the IntelliSense errors would returns. I even tried uninstall/reinstall of Visual Studio.
I had the same issue on two machines, both with same version of Visual Studio.
By looking at the errors about missing types, they all appeared to come from two referenced projects. One of those references was a shared project used by just about every other project in the solution, but one of them was a small project without many references. It just so happens that the small project was also referenced by my larger shared project. In Visual Studio, I unloaded the small project and reloaded it. The errors went away! They errors did not come back on Rebuild Solution.
I then switched Git branches and the errors all came back. Fortunately I repeated the above steps of unloading/reloading the small project and the errors went away.
Every time I switch Git branches, the errors come back until I repeat that process. There are zero changes between the Git branches for the smaller project that I unload/reload. Unclear why that sequence is fixing my issue.
Also had this problem (the title, not the specific error message), as well as squiggly lines in the editor. The first squiggly line is under the first #include statement, which names a precompiled header. Intellisense fails to include the precompiled header, but doesn't list that as an error; instead it lists errors further down the file, on code that (very rightfully) relies on declarations in the precompiled header.
The reason Intellisense doesn't find the precompiled header in my environment is that the header named is not an actual file. It doesn't have to be in any other VC or gcc version I used, nor in the 2015 compiler, as long as the precompiled header settings are correctly configured. Apparently not any more for Intellisense. I'm not entirely sure it was different in 2013, maybe I just never noticed.
In the unlikely case that this would be the problem reported here, the solution is simple: create a small file with the pretend-name of the precompiled header, as specified in #include directives, and let that file include the actual name of the precompiled header.
If you wonder... why this distinction between the precompiled header name in the '#include' statement and the actual filename of the precompiled header? Precisely because it guarantees that precompiled header settings are correctly configured. Wherever a precompiled header is "#included", there is no file around that could be included. Either an actually precompiled (binary) version of the actual header is read, or the compilation fails. Obviously, a disadvantage is that it confuses people reading the code, not just Intellisense.
Visual Studio 2017
I have deleted ".suo" file from location .vs\SolutionName\v15.suo
And then restarted Visual studio. This worked for me.
Today I've had similar problem with MSVC++ 2015. I almost gave up and decided to go on without IDE hints, but suddenly I've noticed that stdafx.h of the project i had problems with doesn't contain any standard library headers. I've speculated that inclusion of all standard headers used in the project in stdafx.h might boost up compilation speed, however doing so fixed Intellisense errors as well.
In Visual Studio 2019 the problem is with changing branches with Git when there are NuGet packages installed in the project. What I did to solve this:
Clean Solution
Close Visual Studio
Delete the packages folder
Open Visual Studio
Go to Package Manager
Restore all packages
Recompile
If roslyn is missing, close and open Visual Studio, then recompile.
I had multiple stdfax.h in Additional Include Directories. Make sure the stdafx.h you intended is first in your path.
I had a similar issue with different Visual Studio versions.
Deleting the .suo or .vs folder did not help for me.
The Solution for me was, that I had the Extension StopOnFirstBuildError active. After turning off "Stop build on first error" in the build menu, and after the solution was fully built, the errors shown by Intellisense went away.
I was seeing the intellisearch errors only when publishing a website. (ASP/C# site, VS 2017). They broke the publish. Site ran fine locally.
Cleared the errors by unchecking the setting to pre-compile, and it published fine.
Publish -> Setting -> File Publish Options -> Precompile during publishing
I had this issue with a reference to another project. Removing and re-adding the project reference worked for me.
Certain nuget libraries seem to force my project to rebuild (as in run fsc.exe to produce a new binary) every single time I build the solution, even if nothing at all has changed. As soon as I delete the reference in the Visual Studio references tree, fsc.exe is no longer called until I actually make a change.
I don't actually need any code at all to reproduce this problem - an empty main function in a project referencing a problematic library will face this issue.
After some trial and error two nuget libraries which definitely cause this problem are:
FSharp.Actor-logary
Newtonsoft.Json.FSharp
but it may well apply to others.
I read in a comment elsewhere on stack overflow that type providers always force recompiles, is that true? My empty test project doesn't use type providers, but maybe these libraries do.
I am using Visual Studio 2013.
I think I've solved it: the problematic libraries have a last modified date of 15/12/2030
I've opened an issue on the project's GitHub page: https://github.com/logary/logary/issues/74
This has been solved when MSFT fixed their assembly-generation bug in mono.
Visual Studio sometimes decides to rebuild my entire huge project because of one small change. I turned build logging up to Diagnostic to see what was the problem, and here's what I'm seeing:
< Bunch of spam >
Outputs for C:\<snip>\PRECOMPILEDHEADERS.CPP:
C:\<snip>\PRECOMPILEDHEADERS.OBJ
All outputs are up-to-date.
Forcing rebuild of all source files due to a change in the command line
... and then it rebuilds my precompiled headers, then everything else.
This happens when I change a single .cpp or .h file inside the project. I'm not changing anything in the project settings. It also doesn't happen all the time for the same change; it's random.
Any ideas on what's going on here? Where can I get more information? I tried enabling debugging via the description in http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx but it didn't give any more information. I can't figure out where this "Forcing rebuild of all source files due to a change in the command line" is coming from. It's not in any of the factory MSBuild files.
Some other info: it's a C++/CLI dll project that links a lot of other projects, including C#, native c++, and other C++/CLI dll's. I tried removing all the C# projects from the dependencies since those tend to cause problems, but that didn't change it. I've googled that specific string, but my situation doesn't match that of any of the other people reporting it. (One was using Intel C++, another was MSBuild from the command line and changing the case. I'm hitting build solution from within Visual Studio itself).
Edit to explain common fixes I've tried:
I've tried building only the project. Does the same thing.
I'm not including any .h files that don't exist.
I've deleted the bin/object folders and rebuilt from scratch. This usually makes it go away for a couple builds, but then it comes right back.
Edit #2:
Found something suspicious earlier in the log:
3>Using "ResolveNonMSBuildProjectOutput" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "ResolveNonMSBuildProjectOutput"
3> Resolving project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj".
3> Project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj" has not been resolved.
This is repeated for several of my projects... I'm gonna chase that down and see if maybe it's a problem with the project reference hint paths.
Ok, it's an old thread, but I encountered the same problem recently.
My solution was to disable the precompiled headers - now a simple change in one sourcefile won't lead into a "rebuild" any more.
I have had the same problem with Visual Studio 2012 recently. I'm on Windows 7 with Visual Studio 2012 Professional (2012.2) building C++ projects. It's worth noting that I recently migrated the solution from Visual Studio 2008 to Visual Studio 2012.
One of the C++ projects (an executable with a DLL project as a reference) was rebuilding every time one of its compilation units was changed, e.g. simply saving main.cpp would cause all compilation units (including the pre-compiled header) to rebuild. I spotted the the following message in the build logs:
Forcing rebuild of all source files due to a change in the command line since the last build.
I turned build log file verbosity to Diagnostic (Tools > Options > Projects and Solutions > Build and Run) and compared the log files from a clean build and a build after one compilation unit has been changed (which forced a full rebuild). I noticed that:
"Path" had changed from one build to the next (";C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\VsGraphics" seems to have been tacked on the end)
there was a difference in TaskTracker.exe command lines to do with CancelEvents
there was a warning about OutputPath not being set
I pulled my hair out.
I eventually resorted to recreating the offending project from scratch rather than relying on the project that was automatically generated during the migration process from 2008 to 2012. It seems to be behaving as expected now.
I did three things, and the problem seems to have gone away. I'm trying to narrow it down a little but I figured I'd go ahead and post them:
Deleted and re-added all the references and project references
Fixed one of my projects that wasn't setting the .NET framework target to 3.5 to match the rest of my solution (I was getting away with it because the project didn't use .NET anyway)
Set "Copy Local Satellite Assemblies" to false for all references including System ones.
Beware that some or all of this stuff might be voodoo...
Source code that compiles fine on other peoples environments won't correctly work in my environment. When I do a rebuild the compile occurs but when visual studio goes to move the exe from /obj/debug/{solution} to /debug/{solution} it cannot find the exe in the /obj/debug/{solution}. To make this even more crazy even after I reinstall visual studio it doesn't work. On other people environments it works find. Please note that this is a windows mobile 6, compact framework 3.5 project, Visual C++ project.
EDIT: Visual Studio 2008 is being used.
EDIT2: After looking at the logs again come to find out it says it is compiling but it isn't really compiling. Interesting enough it doesn't throw any errors until it tries to link the code. When it goes to link the object files, they aren't there and it fails.
I got TWO Release folders: one in the solution folder and one in the project folder. The former contains the .exe file, the latter does not.
In the solution properties page, check whether the path you are expecting the exe to be is same as the one specified in Linker -> Output file.
Another obvious mistake could be, check what build configuration you are building. You might be doing a release build and expecting a debug executable file :) I have done this a few times.
Maybe VS creates the exe, and before it tries to move it to the final destination your virus scanner grabs it and removes it, or moves it to a save location.
I just wanted to chime in and ask: have you looked for the *.exe file name from the directories above? What I found in my case was it was writing to the directory right above the /release subdirectory. Not sure how I missed that detail, but I did! I suppose it never occurred to me earlier because I saw the buildlog.htm being written to the /release subdirectory, and the very existence of the directory itself. In my case it was compiling, linking, etc. I just wasn't able to see the *.exe in that /release subdirectory.
There are two subtly different paths. I was looking here, which doesn't exist:
C:\Users\james\source\repos\CppHelloWorld\Release\CppHelloWorld.exe
The actual exe is here - note the path contains the x64 platform that it was built for:
C:\Users\james\source\repos\CppHelloWorld\x64\Release\CppHelloWorld.exe
In general, the path seems to be:
$PROJECT_PATH\$PROJECT_NAME\$PLATFORM\$CONFIGURATION\$PROJECT_NAME.exe
If the exact same solution works on other machines, then it's an environment problem and no amount of looking at the project, linker, etc is going to resolve this. What is different about the environments? Are the same service packs and QFE's applied for not just Studio, but also the OS? Is there a difference in processors (64/32-bit)? Are your permissions the same? Do you have the same SDKs installed?
I'd agree with Shahi that just trying to build a "hello world" app against the same SDK and see if it will compile is valuable info.
I had exactly the same problem. Just close Visual Studio and reopen it again (basically restart it) and it should work.
In my case, my network security team released an unannounced security update that preventing me from creating any .exe files. I figured that out at midday after trying all the solutions (+ more) here.
Perhaps you do not have write permission to the output folder? If you are running on Vista/7, is your Visual Studio running as elevated?
I've found this to be random for myself in now VS2016. My work around has been to just create another project and copy the contents from the one with out the .exe to the new one. For some reason the new one normally will have the proper .exe and location needed. While this isn't a complete solution at least it's been working for me for the time being.
It happened with me today:
TL;DR; You might be using some C# code in your project who belong to a language version which is not supported by the .NET Framework version targeted by your project
Details:
I had two projects in my solution. One project was already existing. I added a new project targeting most recent .NET Framework v4.6.1 supported by Visual Studio(VS) 2017 class library project template. I used some C# language features which is present in C# v7.0. In such a case, VS can compile the project but can't create the output in bin directory.
Eventually I had to merge the new project code files into the existing old project which was targeting .NET Framework v4.5.1.
So I changed the target Framework version to the latest .NET Framework v4.6.1 for the existing projects also. Then the old project also started supporting my newly pasted C# language features.
In my case, the error appeared after I cloned my solution on a new machine.
I did not realise that the newly-cloned solution had AnyCPU set by default, when in reality my solution only supported x64. The compiler, however, did not return any error.
What pointed me in the right direction was the Output log, highlighted that of the 4 projects my solution was composed of, one of them was always skipped, i.e. only 3 were actually compiled. Scrolling up a bit the log, I noticed some message similar to MSIL mismatch between CPU versions.
Switching from AnyCPU to x64 solved the error for me.
(I then deleted the AnyCPU option from the Configuration Manager to avoid this issue in the future)
If you create a new "hello world" WM project, does it work?
If so, you can compare the solution files to check for differences that can cause this.
As far as I could tell, you need to "Save All" before building.