Question 'var_name' n'est pas déclaré. Il peut être inaccessible en raison de son niveau de protection. en mode débogage


Ce comportement se trouve dans une solution d'application Web vb.net avec plusieurs projets de bibliothèque de classes référencés par l'application Web.

Le code compile, mais en mode débogage, certaines fonctions / sous-routines dans les bibliothèques de classes référencées ont des variables locales qui affichent

'var_name' n'est pas déclaré Il peut être inaccessible en raison de sa   Niveau de protection.

dans la montre et les fenêtres immédiates.

Mouse_over intellisense ne fonctionne pas sur ces variables locales.

Dans certaines sous-fonctions, les valeurs des variables sont accessibles jusqu'à ce que j'entre dans une Try..Catch

Toutes les variables passées dans la sous-fonction / fonction sont accessibles. Les variables définies au niveau de la classe sont également accessibles.

Ce comportement est nouveau dans le code qui est dans la solution depuis des années. La portée des sous-routines et des fonctions n'a pas changé (elles sont publiques).

Ce n'est pas cohérent non plus. Dans un projet de bibliothèque de classes donné, les fonctions / sous-routines publiques d'une classe auront des variables locales dans lesquelles vous pourrez voir leurs valeurs, tandis que d'autres afficheront le message ci-dessus.

Les choses que j'ai déjà essayées:

* 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

J'ai plusieurs solutions dans TFS et c'est la seule solution qui montre ce comportement.

Un de mes collègues a obtenu une copie de la même solution dans TFS et le comportement ne se produit PAS dans sa copie locale.

Ce comportement ne s'est pas produit dans VS2010.


Voici un exemple de déclaration de méthode et de variable locale dans laquelle ce comportement se produit. Si vous parcourez les déclarations et que vous surveillez les variables locales ou les instructions utilisant les variables locales, vous verrez

'var_name' n'est pas déclaré Il peut être inaccessible en raison de sa   Niveau de protection.

comme valeur de la variable dans la fenêtre watch / quick watch / immédiate

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

MISE À JOUR: Je suis allé de l'avant et reformaté / reimaged mon ordinateur portable et installé VS2013. Le problème n'apparaît plus.


12
2018-02-21 15:08


origine


Réponses:


Ce n'est pas exactement une solution permanente, mais j'ai trouvé une solution pour cela dans un projet que je modifiais pour un ami à moi. Même si je ne pouvais pas supprimer le bogue de façon permanente, j'ai constaté qu'il ne rapportait pas ces erreurs si les pages concernées n'étaient pas réellement ouvertes pour modification.

Ce que je devais faire était de les enregistrer, de les fermer de l'éditeur, puis de compiler le projet. Le projet compilerait correctement une fois que j'aurais fait cela, et après qu'il aurait été compilé, il ne rapporterait plus ces erreurs même une fois que les pages ont été ouvertes pour l'édition (bien qu'une modification ou autre puisse causer le problème de nouveau - mais chaque fois, la solution était la même: fermez tout, compilez, puis rouvrez tout ce dont j'ai besoin pour éditer.


4
2018-02-10 01:13



Il y a quelques mois, je traitais exactement le même problème dans VS2013. C'est un bug exaspérant que Microsoft est (dernier que j'ai vu) incapable de reproduire. Pour moi, ça allait et venait sans raison apparente. Les premières fois, je m'en suis débarrassé en faisant certaines des choses que vous avez déjà essayées ci-dessus. Mais alors il est revenu et je ne pouvais pas m'en débarrasser. Ce qui a finalement fait le tour était de désinstaller et de supprimer toutes les traces de toutes les versions de Visual Studio (y compris un balayage manuel du registre), de supprimer tous les codes, projets, solutions, etc. et de supprimer toutes les versions de .NET.

Ensuite, j'ai remis .NET, réinstallé VS2013 et obtenu les dernières nouvelles de TFS. Depuis lors, il n'est pas revenu. Bien sûr, j'espère que non. Bonne chance!


2
2017-12-02 20:47



Essayez de CleanSolution, il a semblé le réparer pour moi.


1
2017-12-08 15:32