vb.net 'var_name' 未声明。由于其保护级别，它可能无法访问。在调试模式

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

提问by user3337755

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

此行为在具有 Web 应用程序引用的多个类库项目的 vb.net Web 应用程序解决方案中。

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.

'var_name'未声明。由于其保护级别，它可能无法访问。

in the watch and immediate windows.

在手表和直接窗口中。

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

mouse_over 智能感知不适用于这些局部变量。

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

在某些子/函数中，变量的值是可访问的，直到我进入 Try..Catch

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

传递到 Sub/Function 的所有变量都是可访问的。在类级别定义的变量也可以访问。

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.

我在 TFS 中有多个解决方案，这是显示此行为的唯一解决方案。

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

我让一位同事在 TFS 中获得了相同解决方案的副本，并且在他的本地副本中没有发生这种行为。

This behavior did not occur in VS2010.

这种行为在 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.

'var_name'未声明。由于其保护级别，它可能无法访问。

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

作为监视/快速监视/立即窗口中变量的值

Utility1.vb

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.

更新：我继续重新格式化/重新映像我的笔记本电脑并安装了 VS2013。问题不再出现。

回答by Rob Wilkins

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.)

我必须做的是保存它们，将它们从编辑器中关闭，然后编译项目。一旦我这样做，该项目就会正确编译，并且在编译之后，即使打开页面进行编辑，它也不会再次报告这些错误（尽管最终，某些编辑或其他操作会导致问题再次发生-但每次，解决方案都是一样的。关闭所有内容，编译，然后重新打开我需要编辑的任何内容。）

回答by Casey Crookston

A few months back I was dealing with exact same issue in VS2013. It is a maddening bug that Microsoft is (last I saw) unable to reproduce. For me, it came and went with no apparent reason. The first few times I got rid of it by doing some of the things you have already tried above. But then it came back and I could not get rid of it. What finally did the trick was uninstalling and removing all traces of all versions of Visual Studio (including a manual sweep of the registry), getting rid of all code, projects, solutions, etc, and removing all versions of .NET.

几个月前，我在 VS2013 中处理完全相同的问题。这是一个令人抓狂的错误，微软（我最后一次看到）无法重现。对我来说，它来来去去没有明显的原因。前几次我通过做一些你在上面已经尝试过的事情来摆脱它。但后来它又回来了，我无法摆脱它。最终的诀窍是卸载并删除所有 Visual Studio 版本的所有痕迹（包括手动扫描注册表），删除所有代码、项目、解决方案等，并删除所有版本的 .NET。

Then I put .NET back, re-installed VS2013, and got latest from TFS. Since then, it has not come back. Sure hope it doesn't. Good luck!

然后我放回 .NET，重新安装 VS2013，并从 TFS 获得最新版本。从那以后，它再也没有回来。当然希望不会。祝你好运！

回答by Brownish Monster

Try to CleanSolution, it appeared to fix it for me.

尝试CleanSolution，它似乎为我修复了它。

回答by BoiseBaked

When it comes to a WinsForm app written in VB.NET, this can happen if the backing code file for the "{Whatever_Form}.vb [Design]" tab, {Whatever_Form}.designer.vb code file, is corrupted by the Visual Studio designer logic. The control symbol that is supposedly "...not declared. It may be inaccessible..." is declared at the wrong scope within Sub InitializeComponent() within the {Whatever_Form}.designer.vb code file, the "Me." prefix is missing, "Friend WithEvents Foo As Type" statement is missing and/or all of the above. The way to fix it is to directly edit the {Whatever_Form}.designer.vb code file leaving the correct {Whatever_Form}.vb source untouched. Edit all the inconsistent declarations having to do with the symbol of the {Whatever_Form}.designer.vb code file which is listed out using the "Find in Files" Visual Studio menu item.

对于用 VB.NET 编写的 WinsForm 应用程序，如果“{Whatever_Form}.vb [设计]”选项卡的支持代码文件 {Whatever_Form}.designer.vb 代码文件被 Visual工作室设计师逻辑。在 {Whatever_Form}.designer.vb 代码文件“我”中的 Sub InitializeComponent() 中，在错误的范围内声明了据称“...未声明。它可能无法访问...”的控制符号。缺少前缀、缺少“Friend WithEvents Foo As Type”语句和/或以上所有内容。修复它的方法是直接编辑 {Whatever_Form}.designer.vb 代码文件，保留正确的 {Whatever_Form}.vb 源代码文件。编辑所有与 {Whatever_Form}.designer.vb 代码文件的符号有关的不一致声明，该文件使用“

One thing to avoid to not cause this type of corruption is to not rename the control symbol's property names "(Name)" or event handler procedure names using the Visual Studio Properties tab. Rename symbols from the {Whatever_Form}.vb source file only.

避免导致此类损坏的一件事是不要使用 Visual Studio 属性选项卡重命名控制符号的属性名称“(Name)”或事件处理程序过程名称。仅重命名 {Whatever_Form}.vb 源文件中的符号。

I using Visual Studio 2017 Pro, for a VB.NET WinsForm app targeting .NET Framework 4.7.1.

我使用 Visual Studio 2017 Pro，用于面向 .NET Framework 4.7.1 的 VB.NET WinsForm 应用程序。