Ich kann seit kurzer Zeit im Releasemodus keine fehlerfreien Anwendungen mehr kompilieren. Ich bastele an einem Modulkomplex mehrerer miteinander in Verbindung stehender Projekte, die aufeinander aufbauen und eine Art Referenzkette bilden. Ich weiß nicht, wieso, aber seit kurzem funktioniert das "Endprogramm" nur noch im Debugmodus, im Releasemodus erscheint die folgende Fehlermeldung:



Ebenfalls seit kurzer Zeit tritt auch ein anderer Fehler auf, ebenfalls nur im Releasemode. Bei Fehler Nummer zwei handelt es sich allerdings um eine NullReferenceException in einer Methode des Grundmoduls. Exakt der gleiche Code funktioniert einwandfrei wenn von Visual Studio aus gestartet, lässt das Programm aber mit unbehandelter Exception abstürzen, wenn ich es nach "Neu Erstellen" ohne Visual Studio starte.

So ähnlic hverhält es sich auch mit ersterem Bug. Ich verwende keine COmpilerdirektiven, die mit dem Debug- oder Releasemodus in Verbindung stehen.

Hilfe? :/



PS: Interessant ist auch, dass die .exe im Debugordner einzeln gestartet so schnell läuft, als wäre es eine Releasemode-exe... normalerweise gibt es - wenn ich das Projekt von Visual Studio aus starte - aber große Leistungseinbußen.. ôo

PPS: Ich vermute mal, da sind irgendwelche Verweissache ndurcheinander geraten und falsche .dlls werde nverlinkt.. kann das sein? Ich weiß es nicht, mir kommt das alles spanisch vor.. was kann ich tun?

Grundsätzlich vermute ich, dass irgendwo ein Speicherbereich falsch beschrieben wird. Das heißt, dass du zum Beispiel mehr Speicher beschreibst als an der Stelle zu einer Variablen gehört o.ä., allerdings sollte das bei C# nicht so einfach passieren.

Der Fehler und dass er beim Debuggen nicht auftritt deuten aber darauf hin, denn dann kann es sein, dass du dabei zufällig nur Speicher überschreibst, der dann nicht zum Fehler führt.

Zum Edit:
Das ist kein Wunder, denn die Exe ist keine spezielle Exe, das Debuggen passiert ja, wenn Visual Studio die Exe startet und diese dabei debuggt. Die Exe an sich ist dabei normalerweise gleiche. (Ob es da auch andere Fälle gibt weiß ich nicht, aber eigentlich ist es wie ich geschrieben habe. Es kann aber durchaus sein, dass du eine Exe mit speziellen Debuginformationen erstellen kannst, das geht zum Beispiel in Delphi.)

Wenn die Debug-Exe die gleiche wie die Release-Exe ist, wieso geht dann nur die Debug-Exe? ôo

Irgendwas ist da faul. Ich verwende C# und bleibe ununterbrochen im "safe" mode, keine Pointerspielereien, kein direkter Speicherzugriff.. Vermutungen?


Edit:
Ein Experiment zeigte mir soeben: Wenn ich die Release-Exe in de nDebugordner setze gibt es kein Problem. Heißt, es wird nicht an der .exe selbst sondern an einer der zugehörigen .dll-Projekte liegen. Habe aber auch da nichts compilermodusabhängiges drin!

Ich bräuchte jetzt mal einen Rat zur weiteren Vorgehensweise.. ôo
Gibt es eine Möglichkeit, mir ein paar eventuell hilfreiche Informationen ausgeben zu lassen? Ich habe den Fehler jetzt auf eine Projekt-dll zurückgeführt, die, wenn im Debugmodus kompiliert, fehlerfrei funktioniert, im Releasemodus aber einen Fehler verursacht..

Um da mehr dazu zu sagen fehlt mir die Erfahrung mit C# und dem Visual Studio leider.

Vielleicht könntest du in der DLL Debugausgaben einbauen.
Zudem sollten die Angaben im Problembericht auch weiterhelfen können, wie muss dir aber jemand anderes erklären. In Delphi würde ich damit noch etwas anfangen können, aber wie du im Visual Studio mit den Speicherstellen etc. etwas anfangen kannst weiß ich nicht.

jaenicke hat folgendes geschrieben :

Das ist kein Wunder, denn die Exe ist keine spezielle Exe, das Debuggen passiert ja, wenn Visual Studio die Exe startet und diese dabei debuggt.

Nein, die "Debug"-Konfiguration erzeugt leicht anderen IL-Code. Andersherum wird aber ein Schuh draus: Es ist kein Problem, eine Release-Exe in VS zu debuggen, nur ein paar Feinheiten werden fehlen.
Das würde ich an Fetzes Stelle mal probieren, denn ansonsten hört sich das Problem schon ziemlich merkwürdig an, wenn es sich wirklich nur um Managed Code handelt . Vor allem die Exception hinter dem ersten Fehler wäre interessant. Und solche Fehler-Boxen wie im Hintergrund habe ich noch nie gesehen .

Wie debugge ich denn die Release-Exe in VS? Das hätte ich schon versucht, wenn ich wüsste, wie

Okay, in Ermangelung einer Antwort habe ich mal den Disassembler .Net Reflector mit dem Add-In Deblector zwecks Debugging verwendet. Habe also die im Releasemode kompilierte .exe eingeladen und im Deblector-Debugmodus laufen lassen. Das Ergebnis hat mich ein wenig schockiert.

Es läuft nämlich perfekt! ABER: Wenn ich den DotNet-Reflector verlasse und das Programm normal außerhalb starte, dann tritt der obige Fehler auf. Ich-verstehe-es-nicht!

Ich brauche dringend Hilfe damit, sonst werde ich wohl noch am Sanktnimmerleinstag mit dem problem zu kämpfen haben. Ich bin dankbar für jeden Vorgehensvorschlag und jeden Hinweis. Wer will, kann auch die komplette Assembly haben und bei sich mal durchlaufen lassen.

Fetze hat folgendes geschrieben :

Wie debugge ich denn die Release-Exe in VS? Das hätte ich schon versucht, wenn ich wüsste, wie

Auf "Release" stellen und F5 drücken . Könnte natürlich sein, dass du das schon getan hast, geschrieben hast du es aber noch nicht .

Fetze hat folgendes geschrieben :

Wer will, kann auch die komplette Assembly haben und bei sich mal durchlaufen lassen.

Wenn du das Beispiel so klein wie möglich halten kannst: Gern .

Wenn ich das Projekt in VS auf "Release stelle" und starte, läuft es einwandfrei. Alleine gestartet gibts wieder den Fehler.

In einem anderen Forum habe ich den Tip gefunden, dass in der Debugversion alle Variablen mit 0 initialisiert werden, im Releasemodus aber nicht - ich vermute mal, dass es irgendwie damit zusammenhängt, kann den Fehler aber ohne stacktrace nicht finden!

Gibt es eine Möglichkeit, eine .Net Assembly "still" zu debuggen? Also nichts anderes zu tun als auf Exceptions zu lauschen und dann einen stacktrace parat zu haben? Ich hatte ja gehofft, das oben genannte Deblector-Tool könnte das, aber Fehlanzeige. Visual Studio kriegt das ebenfalls nicht hin, soweit ich das überblicke und "Just-In-Time Debugging" gibts nicht in der Express Edition.
Gibt es sonstige Tools, die mir da weiterhelfen könnten?

Okay, Entwarnung, Problem gelöst. Auch wenn ich nicht verstehe, wieso es jemals existiert hat.

Die Sache ist wie folgt: Ich habe den Fehler in Assembly.GetExecutingAssembly() lokalisieren können. Während Assembly.GetEntryAssembly() sowie Assembly.GetAssembly(Type t) funktionieren, führt die obige Funktion gemeinsam mit GetCallingAssembly() zu ebenjener Fehlermeldung, wenn ich im Releasemode kompiliere.

Kann mir irgendjemand erklären, warum? Wüsste das schon gerne. Ich verwende .Net 2.0, die Codezeile findet sich in einer .dll-Datei, die von der EntryAssembly verwendet wird.

Ideen?

Fetze hat folgendes geschrieben :

Während Assembly.GetEntryAssembly() sowie Assembly.GetAssembly(Type t) funktionieren, führt die obige Funktion gemeinsam mit GetCallingAssembly() zu ebenjener Fehlermeldung, wenn ich im Releasemode kompiliere.

Hm. "Mysteriös" wäre eine Untertreibung . Welche Exception war es nun, die NRE?

Fetze hat folgendes geschrieben :

Ich verwende .Net 2.0

SP2 (kam mit 3.5SP1 raus)?

Nein, die von dem Screenshot oben. Die andere hat sich verflüchtigt, nach dem Workaround ôo

Habe vor kurzem SP1 installiert (nach! meinem Workaround - keine AHnung, ob der Bug danach immernoch besteht) Wo bekomme ich SP2 her? Auf der Microsoft Website finde ich es nicht :/

Fetze hat folgendes geschrieben :

Habe vor kurzem SP1 installiert (nach! meinem Workaround - keine AHnung, ob der Bug danach immernoch besteht) Wo bekomme ich SP2 her? Auf der Microsoft Website finde ich es nicht :/

Gibt es wohl nur im Bundle mit 3.5, jedenfalls auf gewöhnlich Wege. stackoverflow.com/qu...net-framework-20-sp2

Ich habe ein problem. Schon wieder. :/

Genaugenommen ist das Erscheinungsbild identisch. Diesmal allerdings tritt der Fehler in der folgenden Zeile auf (Habe das per Console-Logs nach und vor jeder Zeile getestet):


Wobei buffer natürlich als byte[] deklariert ist und len einen normalen Wert (1207, um genau zu sein) hat. Die Zeile sitzt in der Nähe von diversen Assembly.- und Manifestaufrufen. Ob das was damit zu tun hat? Ich freue mich über jeden Vorschlag oder Kommentar!