Laden...

C#-Debugger bricht mit Zufallsgenerator debuggen ab

Erstellt von Bernhard005 vor 11 Monaten Letzter Beitrag vor 11 Monaten 419 Views
B
Bernhard005 Themenstarter:in
4 Beiträge seit 2023
vor 11 Monaten
C#-Debugger bricht mit Zufallsgenerator debuggen ab

Hallo zusammen,

ich möchte aktuell ei Programm in C# mit Visual Studio 2022 Version 17.6.2 mit einem Zufallsgenerator, der von zwei eingaben bedingt ist und aus zwei verschiedenen Listen auswählen soll, erstellen. Nur leider funktioniert das Debuggen nicht weder als Release noch als "normales" Debuggen. Ich habe als CPU "Any CPU" ausgewählt mit der neusten .NET-Framework Version. Das Programm funktioniert in Visual Studio im Modus "Starten ohne Debuggen" perfekt. Nur möchte ich die Anwendung weitergeben und ohne das Debuggen funktioniert das ja leider nicht, wenn der Empfänger kein Visual Studio hat.

Schonmal vielen Dank für die Hilfe.

Bernhard

2.079 Beiträge seit 2012
vor 11 Monaten

Nur leider funktioniert das Debuggen nicht weder als Release noch als "normales" Debuggen.

Was heißt "funktioniert nicht"? Das ist keine Fehlerbeschreibung.

Ich habe als CPU "Any CPU" ausgewählt mit der neusten .NET-Framework Version

Lies dir das durch: [FAQ] Das .NET Ökosystem - .NET, .NET Core, .NET Standard, NuGet und Co

Du schreibst ".NET-Framework", was nach der alten Umgebung klingt, außerdem muss man in der Neuentwicklung normalerweise kein AnyCPU auswählen.

Für dein Problem sollte das aber nicht verantwortlich sein, das alte .NET Framework funktioniert immer noch, ist bloß alt und wird nicht mehr weiterentwickelt. Umsteigen solltest Du natürlich trotzdem, bei deinem Projekt würde ich mich sehr wundern, wenn es relevante Unterschiede im C#-Code gibt.

Nur möchte ich die Anwendung weitergeben und ohne das Debuggen funktioniert das ja leider nicht

Wer sagt das?
Geht definitiv. Sowohl beim Debuggen, aber auch beim "Starten ohne Debugger" wird eine Version kompiliert, die ohne Visual Studio nutzbar ist, die liegt im bin-Ordner im Projekt.
Du solltest aber lieber die Publish-Funktion nutzen: Tutorial: Publish a .NET console application using Visual Studio
Das "console application" ist nicht weiter relevant, für Desktop-Anwendungen sollte das genauso funktionieren, im Web gibt's aber mehr, daher vermutlich die Unterscheidung.

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.

B
Bernhard005 Themenstarter:in
4 Beiträge seit 2023
vor 11 Monaten

Hallo Palladin,

erstmal danke für deine Hilfe.

Der Fehler ist genau, dass die Konsole und die Programmausführung nach der vollständigen Eingabe beim Release-Debuggen und dem "normalen" Debuggen sich einfach schließt.

Ich arbeite mit der Konsolen-App für C# wie im Anhang. Was tätest du mir empfehlen, ich möchte aber weiterhin in der Konsole die Ausgabe haben wollen?

Die .Net-Framework-Version ist die 4.8.1 wie im Anhang.

Der "Trick" mit dem bin Ordner funktioniert bei mir leider auch nicht, da dort das gleiche wie oben beschreiben passiert.

Das mit dem Publishen funktioniert leider auch nicht. Ich habe da als Speicherort meinen Desktop ausgewählt, und das über CD-Rom es installiert wird und das Programm nicht nach Updates sucht.

Schonmal vielen Dank für die Hilfe.

Viele Grüße

Bernhard

4.939 Beiträge seit 2008
vor 11 Monaten

Es ist normal, daß ein Konsolenprogramm sich nach Beendigung schließt, wenn es vom Windows-Explorer (bzw. Desktop) aus gestartet wurde.

Entweder du erstellst selber eine Schleife in deinem Code oder aber wartest mittels Console.ReadLine()auf die Eingabe des Benutzers (s.a. [FAQ] Konsole schließt sich sofort nach dem Start).

2.079 Beiträge seit 2012
vor 11 Monaten

Aktuell ist .NET 7, .NET 8 gibt's als Preview, .NET 6 hat Long-Term-Support.
Achte bei den Projekt-Vorlagen darauf, ob da ".NET Framework" in Klammern steht, oder nicht.
Mit ".NET Framework" in Klammern ⇒ Alte Welt
Ohne ".NET Framework" in Klammern ⇒ Neue Welt
Nicht gerade intuitiv, aber so ist es eben.

Du solltest die neue Welt nehmen.
Konsole gibt's da natürlich auch, wie auch WPF, ASP.NET, etc.
Du wirst vermutlich von den Top-level statements überrascht werden. Kannst Du beim Projekt erstellen einstellen, oder mit deinem Code ersetzen, ist aber Geschmackssache und nicht wichtig.

Und stell auf Englisch um, ggf. musst Du die Sprache im Visual Studio Installer installieren.
Die meisten relevanten Quellen sind auf Englisch, da lohnt es sich, auch mit Englisch zu arbeiten.


Und dein Problem:

Der Fehler ist genau, dass die Konsole und die Programmausführung nach der vollständigen Eingabe beim Release-Debuggen und dem "normalen" Debuggen sich einfach schließt.

Das klingt, als wäre dein Programm einfach zuende:
[FAQ] Konsole schließt sich sofort nach dem Start
Im Release-Build verhält sich Visual Studio an dem Punkt anders, wobei das bei mir seit Win11 auch nicht mehr der Fall ist, da startet er das Terminal und das bleibt dann auch offen.
Also entweder Du hinderst das Programm daran, sich zu beenden (Console.ReadLine, oder Console.ReadKey), oder Du baust eine Funktion an, dass es z.B. immer in's Menü zurückkehrt. Letzteres wäre definitiv verständlicher für den Anwender.

Oder Du hast einen Bug in deinem Code, der abhängig von Debug vs. Release ist.
Hält er an, wenn Du am Anfang der Main-Methode einen Breakpoint setzt?
Wenn ja, dann debugge bis zu dem Punkt, wo sich das Programm beendet, dann weißt Du, wo der Fehler ist.
[Artikel] Debugger: Wie verwende ich den von Visual Studio?

Das mit dem Publishen funktioniert leider auch nicht. Ich habe da als Speicherort meinen Desktop ausgewählt, und das über CD-Rom es installiert wird und das Programm nicht nach Updates sucht.

Klingt so, als hättest Du was falsch gemacht, eigentlich funktioniert das Publishen ins Dateisystem ziemlich einfach.
Du musst natürlich auch einstellen, dass er nur in einen Ordner publishen soll, ansonsten versucht er noch andere Dinge, die zu diesem Fehler führen könnten.

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.