So this just started: When I'm debugging a method, VS debugger does not recognize variables or objects that have been declared within the method I am debugging. When I hover over them, it does not give any pop-up intellisense. If I add it to the watch, it says:
'FooBar' is not declared. It may be inaccessible due to its protection level.
It can be something simple, like:
Dim MyString String = "this is a test"
But after moving past that line in dubugger, it won't recognize MyString. BUT, if I then use MyString, like save it to the DB or output it to the screen, it works fine. So it's really there, but debugger is not recognizing it.
Variables and objects that are passed into the method work just fine, as expected.
The first time I saw this, I did a clean & rebuild, and that solved the problem. But a few debugs later, it started up again. A clean & rebuild did not work. So I closed VS, deleted the solutions .suo file. After starting VS back up again, debug now worked as normal, for a while.
But now it's doing it again, and nothing I try seems to get it back working again.
I spent time on Google and have found people who have asked the same question, but I've not seen any thread anywhere with a definitive answer.
Anyone ever seen this before and whooped it?
EDIT AFTER:
Pretty sure I am doing this in debug mode. But let me know if there is some other place I should be looking.
My guess is that you are debugging a 'Release' configuration. Release configurations optimize the code by, among the many other optimizations, removing code that it knows for sure is never going to be used. So, for example, Dim MyString String = "this is a test" will be optimized out of the solution if it is never used but if you add a line of code to commit it to a database it is then being used and will not be optimized out. Switch to the 'Debug' configuration to prevent these types of optimizations.
Related
For some unknown reason, my visual studio adds many break marks in my code.
Some where I believe i had some in the past and some in utterly nonsense positions.
I have found nothing in the web. Dont know if thats a bug or if I am using it incorrectly.
Anyone had that before or knows how to resolve this?
I can remove them point by point until my app runs through but as soon as I start debugging, they are beeing readded. When I stop debugging, they are gone again. I was even able to capture one sample beeing added:
It litterally makes debugging impossible. I cant remove 50 break points whenever I want to debug...
Workaround #1
I have found kind of a workaround by going over Debug -> delete all Break points.
Be aware, this will delete your wanted breakpoints as well.
Lately, VS has been getting more and more annoying about warning me about editing code while debugging. Regardless of whether it is a popup telling me that a file has been edited, purple underlining, or a warning that gets grouped with the compiler warnings and errors, I don't want it. I wish it would just let me edit, continue running the program that was built, and keep quiet about it.
Is there a way to tell it to do that?
Incidentally, I have already disabled edit and continue. See Edit and Continue: "Changes are not allowed when..."
You can apply changes to the source code in debug mode when you stop at a breakpoint.
Manual: How to: Apply Edits in Break Mode with Edit and Continue (Visual Basic)
This is a workaround but some workarounds, well, work.
Run two instances of VS on the same solution. Debug one and encounter needed edit. Ctrl+TAB to the other instance and make the edit (without saving... by the way use auto-save). Continue until you’re done, and then save the files in instance 2. After debug, the changes are available to both instances.
Rarely (at least in my experience) do you actually want edit-and-continue; usually you’re watching the code under debug and realize it is wrong and want to fix it, but also want to see some downstream effects without killing the debug session.
This gives you that with a minor inconvenient task switch.
I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.
I have no idea how this started so I'm guessing there's a setting somewhere that I've been unable to find. I have a test that calls a method but when I run debug, it simply will NOT step into that dll. At all. Period. Throws an exception just fine, but it's kind of worthless when I can't step into see what's actually going on.
When another team member picks it up, he's able to debug the exact method I was attempting to target. Yes, same breakpoints, yes, same code (I checked in, he got it, ran just fine)
What the hell?
update : checked the test project for stupid entires, deleted the debug/release folders for fun, I've went though and dumped the project completely and got it back out of tfs. I've nuked the appdata/local/ms/vs/10.0 folder and the /appdata/roaming/ms/vs/10.0 folder. Deleted the local test results.
You probably need to investigate your project references. Is the DLL possibly GAC'd? Take a close look at the *.csproj file.
The fact that it can be debugged no problem on someone else's machine indicates to me that you're having an environment issue. Some sort of multiple library reference issue.
Another possibility: Visual Studio (and all its embedded tools) can have many strange caching behaviors. You might want to clear out extraneous MSTest-related temporary cache files/dirs.
Ok, got it. You can't do one of those things and it works. I had to do them all prior to opening up vstudio again. It'll blow your settings away just as a heads up.
Kill the AppData/Local/Microsoft/visualstudio/10.0 folder
Kill the AppData/Roaming/Microsoft/visualstudio/10.0 folder
Kill your entire project ... all of it.
Get latest (force)
And it works again.
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