4

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.

enter image description here

enter image description here

Casey Crookston
  • 13,016
  • 24
  • 107
  • 193

1 Answers1

3

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.

Jason Boyd
  • 6,839
  • 4
  • 29
  • 47
  • Thanks. Two things. There are plenty of objects and variables that are declared locally in this method which get used a ton. NONE of them are recognized by the debugger. That being said, when you say, "Switch to the 'Debug' configuration"... pretty sure I'm there already. I'll add a screen shot to my OP. – Casey Crookston Jan 09 '15 at 20:13
  • 1
    Yeah, that definitely does not sound like an optimization issue. Not sure which of the many projects there is the culprit but I would be curios to know what happens if you delete the bin and obj folder from the project before doing a rebuild. Or even just the bin folder. I am wondering if the PDB files are corrupt or somehow not being rebuilt. – Jason Boyd Jan 09 '15 at 20:27
  • Thanks. I'll try those suggestions and get back to you. – Casey Crookston Jan 09 '15 at 20:28
  • 1
    Grrr. None of that helped either. I also wiped out all my local source and got latest from TFS. None of my co-workers are having this issue. Seems to maybe have to do with VS itself, and not any of the project/solution files? – Casey Crookston Jan 09 '15 at 21:02
  • 1
    http://stackoverflow.com/questions/21937998/var-nameis-not-declared-it-may-be-inaccessible-due-to-its-protection-level – Casey Crookston Jan 09 '15 at 21:07
  • No kidding, that would be horrible. If there is an issue with VS or .NET then there is nothing that can be done. So let's operate under the assumption that that is not the case and see where that gets us. I do not know which project is the offending project but I am going to guess it is not the project being executed (call that project A) but rather another project being referenced by that project (call that project B). I would start by investigating the modules being loaded by project A using the Modules window (found under Debug/Windows). Continued... – Jason Boyd Jan 09 '15 at 21:40
  • The build process should build project B first. When project A is built it should copy the required dependencies (DLLs and PDBs) from project Bs bin folder to project As bin folder. I would start by inspecting the paths of the loaded modules to see where they were loaded from. I would also confirm that the files in project As bin folder are indeed copies of the latest files from project Bs bin folder. – Jason Boyd Jan 09 '15 at 21:43
  • 1
    So, I thought I would come back and address this again, for anyone who happens to come looking for an answer. After starting to look into the suggestion above by Johnny, VS kept acting weird. I made a command decision to un-install it and re-install it. But when I tried to run the un-installer, it totally froze my entire system. Re-boot, try again, same result. Re-boot, try again, same result. So I found and downloaded a third party uninstaller that works via brute force by removing all files and registry entries. This process took several hours, but eventually... – Casey Crookston Jan 21 '15 at 22:48
  • 2
    ... I managed to remove all traces of all versions of VS. But when I tried to re-install VS 2013 (Premier w/ Service Pack 4), I got the SAME result. Totally froze my entire box. Re-boot, try again, same result. Repeat. Repeat. Time to involve the IT Help Desk people. Their solution... time for a new work station. They gave me a new laptop. So, to anyone looking for an answer... sorry I can't help. But maybe if you show your support staff this thread, they'll hook you up with a new machine. – Casey Crookston Jan 21 '15 at 22:52