Visual Studio 2017 vs 2019: The breakpoint will not currently be hit. The source code is different
Hi,
ich teste gerade Visual Studio 2019 und hab schon ein Problem, das dann doch sehr stört.
Das Problem habe ich unter Visual Studio 2017 nicht, selbes Projekt, selbe Code-Stelle.
Konkret geht's um einen Breakpoint, bei dem es immer heißt:> Fehlermeldung:
The breakpoint will not currently be hit. The source code is different from the original version.
Natürlich wird das Projekt als Debug gebaut, ohne keine Code-Optimierungen. Neustart von VisualStudio, Clean und Rebuild der ganzen Solution, oder löschen des bin/obj-Ordners (nur vom Start-Projekt) hab ich versucht, es hat aber nicht geholfen.
Das Problem tritt nur bei VisualStudio 2019 (neustes Update) auf, VS2017 kann ich parallel das selbe Projekt auf machen und den Breakpoint an die selbe Stelle setzen, das funktioniert es einwandfrei.
EnableJustMyCode ist auf true gesetzt.
Hat jemand eine Idee, was das Problem ist?
Beste Grüße
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Bei solchen Problemen würde ich den Visual Studio Feedback Knopf drücken.
Dafür ist er da 😉
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ich hatte gehofft, irgendwer hatte schon Mal das Problem und weiß zufällig eine Lösung 😃
Denn die meisten Erfahrungen, die ich bisher dazu gelesen haben, waren sowas wie "Debug statt Release" oder dass man doch bitte die Optimierungen ausstellen soll und das hilft mir jetzt nicht wirklich weiter 😄
Aber gut, dann schau ich Mal, was der Feedback-Button so bringt und ob vom Support wer helfen kann.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Ich hatte das seiner Zeit von 10 auf 15 die Lösung war recht trivial, einfach die betreffende Datei bearbeiten und dann builden, eine neue Leerzeile einfügen hat da gereicht. Die Lösung hatte ich damals auch in einem anderen Forum gepostet, da hat es auch geholfen. Ob das hier jetzt auch funktioniert??
Gruß
Christoph
Das Problem tritt auch bei anderen Klassen in anderen referenzierten Projekten oder dem Startprojekt auf.
Vielleicht bezieht sich das Problem auf das ganze Projekt? Ich hab keine Klassen bearbeitet, sondern nur Projekt-Einstellungen, aber im Anbetracht der Komplexität von VisualStudio wäre das zwar merkwürdig, aber nicht undenkbar.
Aber ich probiere es aus, sobald ich wieder im Büro bin und sag dann Bescheid, ob's funktioniert hat 😃
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Okay ... ich versteh die Welt nicht mehr.
Ich war dabei, das Problem einzugrenzen und habe es sogar im SafeMode (cmd: devenv.exe -safemode) mit einer frischen Consolenanwendung reproduzieren können und beim zweiten Test geht's auf einmal überall wieder O.o
Keine Ahnung, was ich gemacht habe, das ich nicht vorher auch versucht habe, aber mein Problem ist behoben O.o
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Hast du die Option "Require source files exactly match the original version" geprüft?
Du meinst die Einstellung? Die ist auf true
Abgesehen davon sind die definitiv identisch, ich starte das Debuggen ja ganz normal aus VisualStudio heraus, ich attache an keinen Prozess.
Aber mir ist eben durch Zufall etwas aufgefallen:
Eventuell hängt es mit der Art, wie das Projekt geöffnet wurde, zusammen. Zumindest bilde ich mir ein, dass es nach einem Schließen und anschließend erneutem Öffnen der Solution (kein VisualStudio-Neustart!) funktioniert.
Wenn ich das so reproduzieren kann, schreib ich hier und als Report an Microsoft, wie das Problem im Detail aussieht.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Hi,
ich hatte zwischenzeitlich auch mal VS 2019 ausprobiert...
Nach ein wenig Arbeit habe ich mir nun wieder VS 2017 installiert. Dank Side by Side ja zum Glück möglich 😃
Ich hatte die genannten Probleme auch.
Das war bei einer WPF-Bibliothek, bei der ich eine neues Control eingefügt habe.
Und dieses bei dem referenzierten Projekt einfach nicht erkannt wurde...
Nach gefühlten 10x Clean, Rebuild, schließen und öffnen von VS und erneutem Laden der Solution ging es dann irgendwann.
Ich konnte damals das Problem nicht wirklich eingrenzen.
Nachdem mir dann irgendwann die gesamte Solution mit Fehlern, die nicht ersichtlich waren, um die Ohren flog, habe ich den Entschluss gefasst, zurück zu rudern.
Und dieses bei dem referenzierten Projekt einfach nicht erkannt wurde...
Das gibt es aber - wenn ich dich richtig verstanden habe - auch in älteren Versionen.
Der XAML-Editor (den Designer nutze ich nicht) erkennt neue Controls nicht auf Anhieb.
Da hat früher eigentlich ein Rebuild gereicht, wie das bei 2019 ist, weiß ich nicht.
Ich hab es mir aber auch angewöhnt, die Fehler zu ignorieren, da sie den Rebuild nicht verhindern und der Compiler selber den Fehler nicht hat. Also Control einfügen, damit einmal starten und dann geht's auch.
Ist natürlich etwas schwierig, wenn Du andere Compile-Fehler hast, die stören dabei natürlich.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.