While in the middle of working on my app I had an odd issue and, while trying to figure it out, I noticed right clicking anywhere on my code doesn't give me the usual options.
The below image shows what my options are for anything that I click. I should have double or more options to choose from, like opening the document I've right clicked.
The odd issue (which may or may not be related) I had before this started happening was I that I just created a new header and source file. In the source file, VSCode was complaining that it could not find the new header file that I included. I tried including it in a different file, and it could find it there. I'm very confused as to why two files in the same directory are getting different results when they include the same header file.
Does anyone know what happened, and how to fix it?
I have restarted VSCode multiple times, as well as my computer.
I do not know how or why, but while editing code, my c++ extension was uninstalled.
Installing it again has resolved the issue.
I'm writing a C++ wxWidgets calculator application. I recently started getting some random IntelliSense errors that did not however stop compilation. I followed an advice online and performed Clean Solution after deleting the .suo file in my project directory. Now I'm getting 92 errors that do however interrupt compilation, and I have no idea what to do.
"Cannot open error code ".." of source file
Cannot open inclusion file: ".." no setup.h such file or directory
And lots of other erros of these kinds, along with random syntax errors.
I think that the problem might be that VS isn't finding wx/wx.h for some reason.
My setup (don't know if it has anything to do with the errors)
To start programming with wxWidgets, I followed a YT tutorial. I have my wxWidgets files in my D: disk. I have a WXWIN system variable pointing to that directory. In Project properties > C/C++ > General > Additional include directories I have $(WXWIN)\include; $(WXWIN)\include\msvc. Then, in Linker > General > Additional library directories I have $(WXWIN)\lib\vc_lib.
After Clean Solution these options were reset to default (along with _CRT_SECURE_NO_WARNINGS preprocessor) and I had to re-enter them. Now I'm getting all these errors and I don't know what to do.
It seems you simply didn't build wxWidgets itself in x64 release configuration that you use. You must do it before using it.
I also strongly recommend following the official installation instructions rather than tutorials that may be out of date.
Apparently I accidentally changed the combo box left of the "Local windows debugger" button from x86 to x64. I switched it back to x86 (even if I don't know what that means) and everything is back as it is.
Using vs 2017, I've got a solution with 20 projects in it, all C++, none of them that big.
On certain files in one project, intellisense goes extremely slow, or doesn't work at all.
When I select a class member variable name, it doesn't get highlighted. When I git f12, it will pop up the "Intellisense operation in progress..." dialog for 4-5 seconds and will eventually give me a reference in the header and the cpp file for the member variable, whereas usually, it will just go to one of them and not give me a list.
All other cpp and header files work fine, quick response and I get matching-variable highlighting.
The errors pane shows no errors from intellisense or the build. I have no idea what makes these few cpp files special that they don't work.
I've tried removing the project and adding it back, I've tried deleting the .vs directory.
I'm not sure what else to try.
Anybody have any ideas?
Thanks.
When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.
The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.
Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).
Try removing breakpoints from the file in question.
This worked for me when it occurred with Visual Studio 2013 for a header file in debug build.
Source: Release mode file sync issue - current source code different from the version built
Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.
I solved it:
Close the window of the .h file in Visual Studio if it's open.
Close Visual Studio.
CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
Paste the .h file back into its original location.
Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)
This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.
This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.
It took me quite a while to figure this out.
To fix this:
Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).
The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.
I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General
Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.
This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.
The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.
I see the real reason of this question is not answered. So for someone still looking, here it goes...
The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the
particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying.
This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.
this worked for me:
close VS
delete *.vcxproj.filters file
restart VS
problem should be gone.
this worked for me:
clean project
debug/delete all breakpoints :)
This worked for me (as of March 2019):
Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'
I've changed the file name and it works now.
Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.
I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.
This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)
My solutiion:
Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration
It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.
The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.