In Visual Studio 2015 I have two solution configurations 'Debug' and 'Services'. I am able to debug and hit breakpoints with the Debug setting, but not with Services.
To isolate the issue, I have tried to make the Services config look exactly like the Debug config. They both build the same projects and are both set for Any CPU. The only difference I can see between the two at this point is their name.
What settings can cause a breakpoint to not be hit when I can do it with Debug but not Services? And when I mean not 'hit', the breakpoint appears disabled when running as Services.
Running as Debug...
Running as Services...
This is usually caused by one of two different problems.
First, you're not creating PDBs for the particular build configuration. To fix, configure Debug Info for PDB only or Full.
Another possible problem is that the current project isn't configured to build for the current build configuration. In the properties for the solution, make sure it's checked for the current configuration.
If these two don't work, close VS, delete all your bin folders, and try again. If you're still stuck, you have a real problem.
Related
Most of the time, when I build my project, I'm able to attach to breakpoints and debug, as I should. However, sometimes after building, I still get the error “The breakpoint will not currently be hit. The source code is different from the original version.” No matter how many times I build and rebuild it doesn't change it, until seemingly randomly it decides to behave and start working again. How can I fix this when it happens?
Edit: My builds are fine, there are no errors in my builds.
A wild guess...
In "Solution Property Pages" -> "Project Dependencies", choose the project and make sure the dependencies are defined well; for example: if you are using a web service in another project in the same solution, you should make the project including the web service depending on your project or you will not be able to debug the web service.
Of course, I don't know how this option may be bypassed as you say it happens to you randomly.
The text sent is not seen in the Output window.
Solution Configuration is Debug.
Output window is showing output from Debug.
It's a simple command: Debug.WriteLine("abc");
Setting a Breakpoint on it succeeds, but the program breaks on the line after it, moving the Breakpoint!
Changing Platform from Any CPU to x86 solves the issue. But going back, it returns.
Creating a new solution, it does work. Even in Any CPU.
I removed the .suo file for the solution.
I emptied the %temp% folder.
Is there any solution for this?
1) Go to Build -> Configuration manager and make sure you are in Debug mode, not Release.
2) Right-click on the project that you're having trouble with and choose properties.
3) Check the Build tab and make sure Define DEBUG constant and Define TRACE constant are both checked.
Note, most people make the mistake corrected by Step #1. But in my case it was steps #2 and #3 that fixed the problem. Despite being in DEBUG mode, for some reason those two constants were not being defined! I think the IDE may have turned them off when I had some of the projects in a solution using one platform target, and the rest of them using a different one, because by default, they are both enabled (checked) when you are in Debug mode.
This is a weird problem, which luckily (?) also happens on other machines.
I've never had problems with debugging, and now I have: it shows an exclamation mark at my breakpoints which says :'The debugging symbols are not loaded for this document'.
The difference with other projects is that I run this web application in IIS:
I've created a new website in IIS 7.5 (win7), listening on port 80 to
local.comparer.nl
I've added the url local.comparer.nl to my hosts
file, redirecting it to 127.0.0.1
I've edited the start page of the
project (asp.net 3.5) to local.comparer.nl in 'use local IIS
webserver'
When I start the site, it first says 'unable to start remote debugging'. I don't know why it looks for remote debugging, but when I started the remote debugging monitor, it still didn't work.
When I unloaded the debugging monitor, it didn't complain about the remote debugging anymore, but the exclamation mark still was there.
Solutions which -sometimes- help at my colleagues pc's:
Delete everything from the \bin directory and rebuild
Rebuild again (n number of times)
Choose 'clean solution'
Any idea?
Are you building full debugging symbols? If not then the debugger has no information to relate the source code to the in memory activity under the debugger. This is set in the project properties per configuration.
Also ensure the symbols are in the bin folder.
You can validate that VS is loading the right symbols with the Debug | Modules window.
I had this issue bothering me for quite long. Finally, what resolved my problem is :-
1) Make Internet Explorer the default browser
2) Clean the solution
3) Build the solution
In my case I renamed an asp.net page and disconnected the code behind. Strange it still ran but did not run the code behind and therefore did not hit breakpoints in it.
You have to in Visual Studio 2010
Select "Build" Meanu > Clean [Project/Solution Name]
Rebuild [Project/Solution]
Try debug again... Good luck
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally
I'm getting the build error 'error VCBLD0007: Could not find project configuration RELEASE|X64 to build.' when attempting to build in that configuration. Release|Win32 works fine. The configuration definitely does exist in the project. I'm building with vcbuild in VS2005 and running on a x64 box.
Anyone have a hint?
I think your error sounds like one I had a while ago. It turned out to be that we had forgotten to install the 64 bit options when we installed. One way to test was to rerun the installer and choose the change or remove and see if the 64 bit options are already installed or not.
My advice in general in such a situation:
Remove the configuration concerned ("RELEASE|X64") permanently, save and quit visual studio.
To do so, you must choose < Edit...> in the platform popup menu from the configuration manager.
Then restart and and re-create the configuration completely. It might be a good idea, to create some screen shots from the old config before removing it.
That might take some 30 minutes, but it probably will solve the problem.
Just a guess: case sensitivity. Or it could be that the project/solution files are malformed. Check them out - they are simple text files. It would be best if you could provide them here, but I understand that it might not be possible.
Also, in case you don't know this (VS is not very intuitive about this), here's a quick explanation of how the configurations work:
There are two kinds of configurations - each project has its own set of configurations, and the solution has a set of configurations. Each project configuration describes how to build the specific project - compiler options, which files to include, etc. Each solution configuration however only describes which projects to build, and which project configuration to use for each specific project. Note, that there is no 1:1 mapping between project configurations and solution configurations. You can set them up any way you like.
The error seems to suggest that the solution configuration you are using references a project configuration that does not exist in that particular project.
This error was occurring because the 64-bit tools for Visual Studio were not installed correctly. A reinstall fixed my issue.