Okey, I am REALLY having problems with the Visual Studio 2012, and looked all over for a solution, with no result.
So the problem is this... Usually the play button, starts building and debugging in the end running the program. And each time a source file is updated, it should do that again. Well, for me it does not. Every time I write something new in a file, I need to REBUILD the program and then hit play, when before, just hitting the F5 button would do the trick.
The thing is, I have checked, all probable causes that were diagnosed over the internet, so no it's not related to the settings in visual studio, and no, it's not a timestamp issue.
The oddest thing though, is that sometimes, some of the files inside the project look excluded( they have a tiny red circle on them and I have to select and reinclude them). I do not understand why that happens, they were not implemented by me, they are just some "dependency" files on which other classes that I am ussing are built.
Furthermore, the problem of not updating the program. At the moment I have 2 classes. If I write code inside one of them, F5 will work properly and run with the expected modified result. On the other class though, nothing will happen. F5 will find no errors, but it will run without any modification, altough there was code added in one of the classes.
This is really driving me crazy, and I really need a conclusive answer. Why are the dependencies file being involuntarely excluded? Why does visual Build correctly changes from one file but not from another?
You made your visual studio to do it (i.e to launch code with errors).
By default when there is an error you get this popup:
Now if you tick the checkbox - VS will not bother asking you again;
even when errors occur - it will just execute last executable that it has.
To revert this change - go to: Tools > Options > Project & Solutions > Build & Run:
Change this setting to *Prompt to Launch and you are done.
Related
I was debugging fine just yesterday, woke up this morning and all of a sudden I can't use breakpoints. I tried rebuilding, I made sure I was using the right exe and dlls.
What should I do?
-I didn't change configuration settings. I have it on debug.
-When I press F5, it runs, does not promt anything. The only thing is that when I place a breakpoint it says (while hovering over the break point) "no symbols loaded for this document."
-I did not move any files around.
Attept to figure it out: Changed something in the code, looks like that changes was not reflected in the dll, maybe I'm in fact not using the correct files, will look into it...
Alright sorry, figured it out...
Turns out there were TWO dlls, one old version, one new, and my exe was referring to the old version.
Sooo to answer my question: Do a search for all related files to your project, make doubly sure all old files of old builds are deleted. Try changing the code. If changes are not reflected, you know those changes are not going into files you're using.
It been happening for a while now, that every time I make changes to my code and compile, the behavior of program won't reflect the changes I made. What i have to do to get a change is to clean my project and compile all the files again. Visual studio shouldn't be doing this and its starting get in the way of actually debugging my code to begin with as the program is large and it takes a while to compile.
How can I fix this so I don't have to go through this ritual of cleaning then compiling just to see changes.
Aren't your sources on some network/mounted drive? That may confuse the build.
My experience is that it can miss a dependency with some 1% chance on random files, but no more than that.
If they are not, in options/build&run you can set diag level of build to higher and see what steps are considered for build. Also you can look the discovered depencencies in the intermediate files folder, the .tlog files. You may also try to look at debug output as described here though most of the latter belongs to discovering excess compilations...
I've been running and compiling a program on my Windows 7 64-bit machine for several months now, but recently I had to change several VC project settings of the static libs that it uses and now the generated executable file requires me to run it in "Windows XP Compatibility Mode".
Compiled on Windows7 64-bit machine with Visual Studio 2010 SP1
The program I am generating is being built in Win32, debug mode.
The static lib projects specify Target Machine /X86.
When I run the program from the debugger, it start up and runs, however if running via the windows icon, it requires XP compatibility mode.
When trying to start outside of the debugger the EXE shows up in task manager for a second then goes away.
I've tried using Microsoft Application Verifier on it, however I don't know what to look for in the output.
I've been unable to find any details on how to troubleshoot this issue so if anyone has any ways if finding what could be causing this recent Compatibility Mode requirement I'd love to hear how it was fixed.
I have the source/projects/solutions for the majority of the static libs that I link against, as well as the exe file generated, however some of the external dependencies I only have the .lib,.dll, and .h files for. This means I can change (most) of the project settings for the dependencies if neccessary, but I need to know which ones to look for.
Thanks
To be honest, don't be afraid to make another project and copy the code files, even if it's 5 projects. You need to cut the problem in half. If it works with the new projects then it's the project files, if not, it's the code. Making projects isn't that hard really, though I'm sure a source of much consternation and something people avoid. If its the projects you can diff the files and see what happened by process of elimination. If you are really worried, copy the entire solution to another folder; always make backups.
The problem is that you probably won't be able to hoist enough information up to us to get a meaningful answer unless get lucky, and all the answers will be shots in the dark.
So I'm goign to take this question as "this happens, what can I do about it". The strategy above will get you out of it, if this used to work before. This exercise will arm you for the future and will be more productive in the long term. Go look at UAC and manifest files, aka Vista+ difference tht dramatically changes load and run behaviour (Linker Commands, Vista Migration Guide) if you need one thing to look at, but try the above process.
----
Other generic things to try:
1) another machine
2) another install of VS
3) a simple project with one window that does nothing to prove everything else in your tool chain and environment is ok.
4) planting message boxes along the code path with different messages so you know where its crapping out.
5) turing on pdb in release and runnign outside of debugger. If craps out, then try debugging and see if still craps out, but you get to see where.
6) assume that your code is unstable and you were getting lucky when it used to work. (this one is no fun). Many times things work in debug and not in release due to mem layout being different. If your progam is large you can find creative ways to use #if's whatever to elimitate code from running while haivng the whole thing still load. You can find the code that causes the bad behaviour.
7) turn off UAC and error reporting if its on, see if changes.
8) go find the "run without debugging" menu button in Visual Studio, so you don't have to go run it with the icon. That's an accident waiting to happen, and eliminates one more environmental difference. It looks like the run with debugging button, but it's hollow, a plain green triangle. It's under debug menu set. My oppinion is that it has done more harm than good to not have that on the bar by default as its confused many many people to think launching wiht VS means always using the debugger.
and so on....
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.
I experienced this problem in VS2010 before, and solved it looking at this SO question. However, now that I upgraded my VS to SP1, it appeared again. I tried to solve it the same way, enabling C++ projects logging and using DebugView. But I can't get to see any output in DebugView, no matter what I do. I also tried raising the Build output verbosity (Tools->Options->Projects and Solutions->Build And Run), but couldn't find any clue.
As in the original problem, the projects reported as out of date are always unmanaged C++ projects. The solution has C#, VB.NET, C++/CLI and C++ projects. What I'm trying to run is a VB.NET exe which uses some C++ projects through C++/CLI wrappers.
Any hint on how to troubleshoot this?
UPDATE: Solved it with a clean checkout. However, it's a shame that there is no longer a way to troubleshoot this kind of errors...
Is it possible you were testing with the date in the future and saved a source file in the future? While clean/rebuild all should fix this, VS seems to go batty and stay there until I resave the file in the present.
Another last-ditch thing that sometimes solves these problems that works 'like a reboot' if you have just the source-code in version control: Check everything in, close VS and anything using files in your project, move all your project folders to a backup folder, and do a force-get latest version of each. Sometimes 'clean project' doesn't cut it.
If that doesn't work and you can't find a missing .h ... You can always fire up Process Monitor, set a filter, and dig in there.
Admittely all just stabs in the dark. Hope one hits the burgler! ;-)
After a compiler upgrade you should do a rebuild-all, if you haven't done that already.
For native C++ projects you can get "project out of date", but still nothing to build, if you have some include files in your project that doesn't actually exits. Like if you have deleted some unused .h files, but they are still part of the project.