'nom_var' n'est pas déclaré. Il peut être inaccessible en raison de son niveau de protection. ' en mode débogage
Ce comportement se produit dans une solution d'application Web vb.net avec plusieurs projets de bibliothèque de classe référencés par l'application Web.
Le code est compilé, 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
'nom_var' n'est pas déclaré. Il peut être inaccessible en raison de son 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 je passe à un Try..Catch
Toutes les variables passées dans la sous/fonction sont accessibles. Les variables définies au niveau de la classe sont également accessibles.
Ce comportement est nouveau dans le code intégré à 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 ont des variables locales dans lesquelles vous pouvez voir leurs valeurs, tandis que d'autres affichent le message présenté ci-dessus.
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 reçu une copie de la même solution dans TFS et le problème ne se produit PAS dans sa copie locale.
Ce problème ne s'est pas produit dans VS2010.
Voici un exemple de déclaration de méthode et de variables locales dans lequel ce problème se produit. Si vous parcourez les déclarations et que vous surveillez l'une ou l'autre des variables locales ou des instructions utilisant les variables locales, vous verrez:
'nom_var' n'est pas déclaré. Il peut être inaccessible en raison de son niveau de protection .
comme valeur de la variable dans les fenêtres watch/quick watch/immediate
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: Je suis allé de l'avant et reformaté/reimaged mon ordinateur portable et installé VS2013. La question n'apparaît plus.
Ce n'est pas vraiment une solution permanente, mais j'ai trouvé une solution à ce problème dans un projet que je modifiais pour un de mes amis. Bien que je ne puisse pas créer le bogue pour disparaître de façon permanente, j’ai constaté que ces erreurs ne sont pas signalées si les pages concernées ne sont pas réellement ouvertes pour modification.
Ce que je devais faire était de les sauvegarder, de les fermer hors de l'éditeur, puis de compiler le projet. Le projet DEVRAIT compiler correctement une fois que je l'aurais fait et après l'avoir compilé, il ne rapporterait plus ces erreurs même une fois les pages ouvertes pour modification (bien que, éventuellement, une édition ou une autre puisse provoquer la réapparition du problème - mais à chaque fois, la solution était la même: fermez tout, compilez, puis rouvrez tout ce que je dois éditer.)
Il y a quelques mois, je traitais exactement du même problème dans VS2013. C’est un bug exaspérant que Microsoft (la dernière fois que j’ai vu) est incapable de se 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 ensuite il est revenu et je ne pouvais pas m'en débarrasser. Finalement, l’astuce a été 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 tout code, projets, solutions, etc., et de supprimer toutes les versions de .NET.
Ensuite, j'ai réintégré .NET, réinstallé VS2013 et obtenu les dernières nouvelles de TFS. Depuis lors, il n'est pas revenu. J'espère bien que non. Bonne chance!
Essayez de CleanSolution, il a semblé résoudre ce problème pour moi.
En ce qui concerne une application WinsForm écrite en VB.NET, cela peut se produire si le fichier de code de support de l'onglet "{Whatever_Form} .vb [Design]", fichier de code {Whatever_Form} .designer.vb, est corrompu par Visual Logique de concepteur de studio. Le symbole de contrôle censé être "... non déclaré. Il est peut-être inaccessible ..." est déclaré dans une portée incorrecte dans Sub InitializeComponent () dans le fichier de code {Whatever_Form} .designer.vb, "Me". préfixe manquant, instruction "Friend WithEvents Foo As Type" manquante et/ou tout ce qui précède. La solution consiste à modifier directement le fichier de code {Whatever_Form} .designer.vb en laissant intacte la source correcte {Whatever_Form}. Modifiez toutes les déclarations incohérentes relatives au symbole du fichier de code {Whatever_Form} .designer.vb, répertorié à l'aide de l'élément de menu Visual Studio "Rechercher dans les fichiers".
Une chose à éviter pour ne pas causer ce type de corruption est de ne pas renommer les noms de propriété du symbole de contrôle "(Nom)" ou les noms de procédure du gestionnaire d'événements à l'aide de l'onglet Propriétés de Visual Studio. Renommez les symboles à partir du fichier source {Whatever_Form} .vb uniquement.
J'utilise Visual Studio 2017 Pro pour une application VB.NET WinsForm ciblant .NET Framework 4.7.1.