vb.net - 'var_name'is not declared. It may be inaccessible due to its protection level.' in debug mode

Question

This behavior is in a vb.net web application solution with multiple class library projects referenced by the web app.

The code compiles, but in debug mode, some functions/subroutines in the referenced class libraries have local variables that display

'var_name' is not declared. It may be inaccessible due to its protection level.

in the watch and immediate windows.

The mouse_over intellisense doesn't work on those local variables.

In some sub/functions the variables' values are accessible until I step into a Try..Catch

All variables passed into the Sub/Function are accessible. Variables defined at the class level are accessible, too.

This behavior is new in code that has been in the solution for years. The scope of the subroutines and functions have not changed (they are Public).

It is not consistent either. In a given class library project, public functions/subroutines in one class will have local variables where you can see their values, while others display the message shown above.

Things I have already tried:

* Clean/Rebuild Solution
* Turn off Code optimizations (it has always been turned off in Debug mode)
* Enable the "Show all members for non-user objects in variables windows (Visual Studio)" option in the Debugging options.
* Import default settings for VS2012
* Update VS2012 to latest version (Update 4)
* Install VS2013 and open solution (behavior occurs there as well)
* Clear AppData cache
* In Advanced Compiler Settings, set 'Generate debug info' to both Full and pdb-only
* Remove local copy of solution and get the solution again from TFS
* All projects in the solution are set to Debug

I have multiple solutions in TFS and this is the only solution that shows this behavior.

I have had a colleague get a copy of the same solution in TFS and the behavior does NOT occur in his local copy.

This behavior did not occur in VS2010.

---

Here is an example of a method and local variable declarations where this behavior occurs. If you step through the declarations and set watch on any of the local variables or any statements using the local variables, you will see

'var_name' is not declared. It may be inaccessible due to its protection level.

as the value of the variable in the watch/quick watch/immediate windows

Utility1.vb

Imports System.Web

Imports System.Text

Imports SPBO

Public Class Utility1

Public oNav_inc As New Navigation_INC
'===========================================================================
'Utility1.vb
'===========================================================================
    Public Sub UTIL_EstablishActivityContext(ByRef Response As HttpResponse, ByRef page As Page, ByRef oGlobal_inc As GlobalVariables_INC)

        Dim oActivity As ENC2.Web.ActivityContext
        Dim oMHardUBO As MHUBO
        Dim oPUBO As PUBO
        Dim asGroup As String = ""
        Dim sGroup As String = ""
        Dim bActive As Boolean
        Dim g_oUserAccountBO As UserAccountBO
        Dim sImplementation As String = ""
        Dim rs As DataSet
        Dim sQuery As String
        Dim rsUser As DataSet
        Dim sUserGroups As Object
        Dim iLoop As Integer
        Dim bInternal As Boolean
        Dim g_bInternalUser As Boolean

        g_bInternalUser = False

        'rest of code

    End Sub

End Class

---

UPDATE: I went ahead and reformatted/reimaged my laptop and installed VS2013. The issue is no longer appearing.

Answer 1

It's not exactly a permanent solution, but I did find a workaround for this in a project I was amending for a friend of mine. Although I couldn't make the bug to go away on a permanent basis, I found that it didn't report these errors if the affected pages weren't actually open for editing.

What I had to do was save them, close them out of the editor, and then compile the project. The project WOULD compile correctly once I'd done that, and after it had compiled, it wouldn't report those errors again even once the pages were opened for editing (though eventually, some edit or other would cause the problem to reoccur -- but each time, the solution was the same. Close everything out, compile, and then reopen whatever I need to edit.)