vb.net - été - visual studio set source code location




Le point d'arrêt VS 2008 ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document (9)

Je me bats pour surmonter cet obstacle et j'ai de grands espoirs que quelqu'un sur SO puisse aider.

Lorsque je définis un point d'arrêt dans mon projet de bibliothèque de classes . Il apparaît comme un point d'arrêt normal. Lorsque je commence à déboguer ma solution, le point d'arrêt devient évidé et comporte un triangle jaune avec un point d'exclamation à l' intérieur. L'info-bulle affichée lorsque je survole le point d'arrêt est la suivante: " Le point d'arrêt ne sera pas atteint actuellement. Aucun symbole n'a été chargé pour ce document. "

Ce projet n'est pas une application ASP.NET, il s'agit simplement d'une application winForms.

J'ai repris une application winForms existante avec plusieurs projets dans la solution. J'ai le projet construit et en cours d'exécution en mode débogage. Je peux m'arrêter à des points d'arrêt dans certains projets, mais je ne parviens pas à atteindre les points d'arrêt dans d'autres projets, en particulier mon projet de type class library .

Ce que j'ai fait jusqu'ici:

  • J'ai supprimé tous les dossiers de débogage et de publication,
  • J'ai supprimé le dossier obj et j'ai reconstruit la solution par la suite.
  • J'ai redémarré l'IDE VS2008.
  • J'ai redémarré mon ordinateur.
  • J'ai vérifié la configuration de Configuration Manager pour vérifier que mon projet de classe est inclus dans la version de débogage.
  • J'ai vérifié les modules debug / pour dll, bien que je n'essaie pas de faire référence à une DLL.

De plus, j'ai suivi les étapes de dépannage décrites dans les publications SO:

le point d'arrêt ne sera pas touché actuellement aucun symbole chargé

VS 2010, NUNit et "Le point d'arrêt ne sera pas atteint actuellement. Aucun symbole n'a été chargé pour ce document "

Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document.

Impossible de déboguer - "Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document "

Correction "Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document. "

En outre, j'ai lu de nombreux articles trouvés sur Google à partir de MSDN et d'autres sites, dont aucun ne répondait à mes besoins spécifiques.

Certains de ces messages sont:

Visual Studio 2008 "Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document"

Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document

Le point d'arrêt ne sera pas touché actuellement. Aucun symbole chargé pour ce document.

Problème de débogueur "Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document

Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document.

Tous les articles que j'ai lus ont été très instructifs, mais aucune des solutions proposées ne correspond à mes besoins spécifiques. S'il vous plaît laissez-moi savoir si plus d'informations sont justifiées. J'ai plus de liens que je peux fournir comme références à ce qui n'a pas fonctionné. Ainsi que des mesures supplémentaires que j'ai prises pour tenter de résoudre ce problème.

Je poste ce suivi pour que tout le monde reste informé. J'ai suivi @Hans @ suggestion pour appeler le fichier de projet en question.

J'ai placé un dim frm sous la forme = new ProjectInQuestion.FormInQuestion

et

cela a maintenant le chargement de l'assemblage dans le debug -> Windows-> Modules

Le nouveau problème est plus complexe que mon problème initial. Mes points d'arrêt ont l'air bien, mais ils sont ignorés. Il n'y a pas d'erreur évidente au point d'arrêt.


Assurez-vous que le debug mode est sélectionné dans Visual Studio avant de commencer le débogage.

Vérifiez la liste déroulante, près du bouton Lecture dans Visual Studio.


C'est peut-être une vieille question, mais je voulais y répondre après avoir trouvé une solution à ce problème, car c'était l'une des questions les plus complètes sur ce sujet.

Introduction

Mon projet est une application ASP.NET, mais le problème de base se produira également sur WinForms. Le problème se pose lorsqu'une DLL est manquante dans la sortie des assemblys. Toutefois, cette même exception se produit si la DLL que vous référencez fait référence à une autre DLL qui ne se trouve pas dans les assemblys. En raison de la manière dont le système d'exploitation charge les DLL, la DLL référencée doit se trouver dans le chemin de l'environnement et non dans vos assemblys de sortie.

Project A fait référence à DLL D. DLL D références DLL X. DLL D peut être dans vos assemblys de sortie. DLL X doit être dans votre chemin d'environnement.

La cause principale de ce problème réside dans la manière dont le système d’exploitation charge les DLL natives à> runtime. Les fichiers DLL natifs sont chargés en utilisant la logique suivante qui n'inclut pas le dossier> Fichiers ASP.net temporaires ni le dossier applications / bin. Ce problème se produira également dans n'importe quelle application .Net si la DLL native n'est pas incluse dans le dossier / bin avec le fichier .EXE> ou si la DLL n'est pas dans la variable d'environnement de chemin d'accès.

Solution personnelle

J'utilisais une DLL appelée DivaAPIWrapper.dll (DLL gérée pour C #). Je savais cependant que DivaAPIWrapper.dll nécessitait DivaAPI.dll (C ++ non géré) pour fonctionner. J'ai placé DivaAPI.dll dans tous mes chemins de sortie mais j'ai continué à recevoir cette erreur. Ce n'est qu'après que j'ai placé DivaAPI.dll dans mon chemin d'environnement (C: \ windows \ Microsoft.Net \ Framework \ v2.0.50727). Veuillez noter que votre chemin peut être différent si vous utilisez une version plus récente du framework .NET!

Solution complète par Jerry Orman

Voir le lien ici: http://blogs.msdn.com/b/jorman/archive/2007/08/31/loading-c-assemblies-in-asp-net.aspx


J'ai également rencontré le même problème et trouvé de nombreuses solutions sur Internet, mais la solution fonctionne pour moi:

C'est dû à mon application faite dans la version 4.0 du framework et j'essayais de joindre un processus avec une version inférieure à la version 2.0, donc assurez-vous que la version de votre framework avec la version du code managé est la suivante.


J'ai eu le même problème avec VS2008 dans une application de formulaires Vb.net où j'ai appelé une DLL dans un autre projet, chargée dans le même groupe de projets. J'ai trouvé cette solution simple: j'ai chargé une instance dans l'événement form_load comme Dim pmg As New PMGExport.PMGExportNeu.


J'espère que cela t'aides...

Je faisais référence à une DLL qui se trouvait dans mon dossier bin \ Release, même si j'étais en mode débogage.

J'ai copié la DLL dans le dossier bin \ Debug et quand j'ai couru VS, le point d'arrêt a été atteint.


Je fais cela tout le temps, comme vous l'avez dit, le point d'arrêt n'est pas actif tant que la DLL n'est pas chargée. Ce n'est pas grave cependant, car il doit charger la DLL avant que le code puisse y accéder de toute façon. Mes points d'arrêt commencent de cette façon mais ils sont toujours touchés.


Une chose que j'ai découverte récemment et qui a bien fonctionné !!!

L'application d'hébergement (celle qui appelle votre dll à utiliser) doit avoir cette ligne:

<supportedRuntime version="v4.0"/>

dans le fichier "WhateverApplicationItIs.exe.config", dans la section <configuration> .

Exemple: (Voir "..." comme tout ce que le fichier contient à l'intérieur et laisser tel quel)

<configuration>
    ...
    <supportedRuntime version="v2.0.50727"/>
</configuration">

PS: essayez de faire correspondre cette version avec le framework cible défini dans les propriétés de votre projet. Je crois que le 2.0.50727 est un bon essai pour 3.5 Framework et 4.0 pour 4.0 Framework.

Pour moi, il suffit de résoudre deux DLL différentes que j'essayais de déboguer dans différentes applications.


Vérifiez que vous n'avez pas changé le processeur auquel vous avez l'intention de compiler ce projet. J'avais, et quand je l'ai changé, tout a fonctionné à nouveau. Apparemment, un changement de processeur le rend «différent de l'original»


essayez ceci, dans Vs 2008, allez à Tools-> option-> Debugging-> General-> unchecked / disable 'Requiert que les fichiers source correspondent exactement à la version originale





breakpoints