I have recently upgraded from Visual Studio 2012 to 2017 and I'm experimenting with the Code Analysis features (which seem to be far more capable than they were in 2012).
The problem I have is that I'll get many results for code dependencies, whereas I am really only interested in my own local project files. This is particularly true when I have Enable C++ Core Check (Released) enabled.
For example, as shown above, I receive multitudes of analysis results for the boost libraries. There are tons of results for xerces-c, and other libraries which I'm using as well.
Is there a way to restrict the analysis to only those files which I have written myself (local to the project)?
There isn't a flag or setting that I'm aware of to directly accomplish this, but you can get something close by using #pragma warning to change the warning level (or disable specific warnings) before you include those library headers, then restore the warning level before including your own.
It isn't perfect, and could result in suppressing warnings you'd want to see, but if you only disable them during Code Analysis that wouldn't be an issue.
I use Visual Studio 2013 to make a CLR-compatible version of my C++ code library ('mylibrary.lib'). It's been working fine for years, but all of a sudden I'm getting 'LNK1104' errors because Visual Studio is looking for 'mylibrarymdd.lib'.
Why is it suddenly, magically tacking on 'mdd' to the library name instead of using the .lib file I specified? And how do I get it to stop doing this?
I've found two workarounds for this problem, but don't like either one of them. Hopefully someone is able to explain why these steps were unnecessary and then all of a sudden necessary.
The first and most obvious work-around is to modify the dependency's project settings so the target output filename matches what the consuming project is expecting -- namely, 'mylibrarymdd.lib'.
The second work-around is to use "/NODEFAULTLIB:mylibrarymdd.lib". This is required for every individual dependency with the auto-naming issue.
To get to the correct (IMHO) solution, one would need to know WHY Visual Studio is creating a "default library dependency" of 'mylibraryMDD.lib' in the first place. As I stated, it wasn't doing so before and there have been no recent updates to Visual Studio or the project files themselves.
I did find that there was a change to a dependency of 'mylibrary'. It pulls in the static OpenSSL libraries and those were updated. It's unclear how that would cause the above behavior, however.
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.
When I build my C+ project in Visual Studio 2010 using Boost 1.54 and toolset v90, I get a bunch of IntelliSense errors (see image below). My project still builds fine and runs as I'd expect. These errors aren't preventing me from working on my code, but they are really annoying. How do I either fix them or hide them?
I found this post that mentions one of the errors. It suggests that I include <boost/cstdint.hpp>. I tried that but nothing changed. I checked greg_calendar.hpp where the error is happening and it already includes <boost/cstdint.hpp>.
I had the same issue, don't know if this helps but my boost directory resides on D drive (D:/boost to be exact) and my project files also reside on D. My reference to it in the Visual Studio Include Directories was '\boost'. This compiled fine as it was on the same drive but intellisense was still saying I had errors so I changed it to be more explicit (D:\boost) and that fixed it up. Hope this helps anyone in the future.
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.