none
Variable qui n'est pas reconnue ? RRS feed

  • Question

  • Bonjour a tous

    J'ai un problème étrange, une variable qui n'est pas reconnue ...
    Apres un problème de debug j'ai eu un problème de point d'arrêt, j'ai du aller dans les Outils/options/Debugging/Général et jai décoché l'option "Require source files to exactly match the original version", cela semble fonctionné pour les points d'arret ... j'ai quand meme des doutes sur le comportement du debug avec l'option que j'ai décoché ...

    Maintenant comme j'ai pu dire dans le titre, j'ai une impossibilité de mettre un point d'arret sur une variable qui "set" une valeur, cela fonctionne pour toutes les autres sauf une ?!!? quand j'essai de possitionner un espion dessus il me dit que : DeskS The name 'DeskS' does not exist in the current context

    Avez vous une idée ?


    Cordialement,


    • Modifié Troxsa mardi 13 mai 2014 09:33
    lundi 12 mai 2014 09:49

Réponses

  • Pouvez-vous nous donner des détails sur la solution?
    Peut-être une capture d'écran avec la solution. 
    Le fait que vous devez décocher "Require source files to exactly match the original version" et ce comportement m'indique que vous n'utilisez le bon DLL.
    Donc soit vous utilisez un Dll trouve dans le GAC ou un qui en effet est un Web Service, héberge sur IIS.
    Peut-être ajouter une capture d'écran avec les propriétés du projet DLL nous sera utile.

    Bien cordialement


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    • Marqué comme réponse Troxsa mercredi 14 mai 2014 21:36
    mardi 13 mai 2014 10:12
  • Aurel a raison: votre problème vient du fait que vous affichez un code source qui ne correspond pas à la DLL en cours d'exécution. Le fait d'avoir enlever l'option vous autorise malgré tout à utiliser ce code source mais le risque, c'est que votre pas à pas peut vous montrer des instructions qui ne sont pas du tout celles qui sont exécutées. Résultat, vous demandez la valeur d'une variable qui n'existe pas. Typiquement, VS va vous interdire de mettre des breakpoints où vous voulez, va s'arrêter sur des lignes blanches en pas à pas, etc.

    Pour comprendre d'où vient votre problème:

    - vérifiez où est copiée la DLL quand vous la compilez

    - vérifiez depuis la fenêtre Modules de VS où votre programme va chercher la DLL que vous cherchez à débugger.

    Si les 2 emplacements ne correspondent pas, vous aurez compris pourquoi il y a ce décalage entre code source et DLL en debug.

    A+

     

    Xavier

    • Marqué comme réponse Troxsa mercredi 14 mai 2014 21:36
    mercredi 14 mai 2014 20:22

Toutes les réponses

  • Bonjour

    A priori il existe un décalage  entre le dll et les sources.

    Vous êtes sûr d'avoir compilé la dernière version des sources et l'utiliser?

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.


    mardi 13 mai 2014 06:11
  • Bonjour Aurel,

    Oui il me semble, les dates correspondes bien dans le dossier bin (debug et/ou release)

    J'ai fait un déplacement des variables un bloc plus haut pour avoir une porté plus importante, et le problème est identique cela bugg toujours sur la meme variable !

    Voila a quoi ressemble les quelques ligne, et ça plante sur la variable Desktop

    RegistryKey PC = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64).OpenSubKey(@"Software\xx-xxx\xxxxxx", false);
    AppInt = Convert.ToBoolean(PC.GetValue("AppInt"));
    ADInt = Convert.ToBoolean(PC.GetValue("ADInt"));
    string Desktop = PC.GetValue("Desktop").ToString().ToUpper();
    Je pensais que Desktop aurait pu être une methode propre a C# et j'ai donc changé de nom et le changement de nom de variable ne corrige pas le bug


    Quand j'ajoute un espion sur :

    PC.GetValue("Desktop").ToString().ToUpper()

    J'obtiens bien la valeur attendu mais elle n'est pas stocké dans la variable "Desktop"


    Cordialement,

    mardi 13 mai 2014 09:51
  • Pouvez-vous nous donner des détails sur la solution?
    Peut-être une capture d'écran avec la solution. 
    Le fait que vous devez décocher "Require source files to exactly match the original version" et ce comportement m'indique que vous n'utilisez le bon DLL.
    Donc soit vous utilisez un Dll trouve dans le GAC ou un qui en effet est un Web Service, héberge sur IIS.
    Peut-être ajouter une capture d'écran avec les propriétés du projet DLL nous sera utile.

    Bien cordialement


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    • Marqué comme réponse Troxsa mercredi 14 mai 2014 21:36
    mardi 13 mai 2014 10:12
  • Aurel a raison: votre problème vient du fait que vous affichez un code source qui ne correspond pas à la DLL en cours d'exécution. Le fait d'avoir enlever l'option vous autorise malgré tout à utiliser ce code source mais le risque, c'est que votre pas à pas peut vous montrer des instructions qui ne sont pas du tout celles qui sont exécutées. Résultat, vous demandez la valeur d'une variable qui n'existe pas. Typiquement, VS va vous interdire de mettre des breakpoints où vous voulez, va s'arrêter sur des lignes blanches en pas à pas, etc.

    Pour comprendre d'où vient votre problème:

    - vérifiez où est copiée la DLL quand vous la compilez

    - vérifiez depuis la fenêtre Modules de VS où votre programme va chercher la DLL que vous cherchez à débugger.

    Si les 2 emplacements ne correspondent pas, vous aurez compris pourquoi il y a ce décalage entre code source et DLL en debug.

    A+

     

    Xavier

    • Marqué comme réponse Troxsa mercredi 14 mai 2014 21:36
    mercredi 14 mai 2014 20:22
  • Bonjour,

    Je viens donner des nouvelles :)

    Il semble que vous avez raisons, j'ai supprimé la référence a la DLL et j'ai remis la DLL en sélectionnant dans le gestionnaire de  références / solution / projet et j'ai simplement coché la référence.

    Elle est maintenant a jour dans tout le projet quand je lance un build, de plus toutes les variables sont reconnues.

    J'ai l'impression que l'importation de DLL dans le projet a été mal fait a la base, je pense que l'option parcourir a ete choisi au lieu d'utiliser l'option du projet dans le référencement (je ne sais pas si c'est clair là).

    un gros merci a tous


    Cordialement,

    mercredi 14 mai 2014 21:35