Autor Beitrag
Fetze
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 65
Erhaltene Danke: 1



BeitragVerfasst: Do 07.02.08 17:37 
Heyho,

ich habe da wohl kürzlich versehentlich was an meiner Visual C# 2005 Express Version verstellt. Das vermute ich jedenfalls weil seit einiger Zeit ein paar dateien mehr im bin/Debug bzw. bin/Release-Ordner liegen (die jeweils ein .vshost im Namen tragen) und ich zusätzlich dazu eine Anomalie im Programmablauf feststelle:

Wenn ich mein derzeitiges Projekt im Debugmodus kompiliere, läuft alles einwandfrei. Im Releasemode (via Rechtsklick --> "Neu Erstellen" oder "Erstellen") allerdings nicht! Es stürzt kommentarlos ab und wenn ich mir eine aufgefangene Exception ins Log schreiben lasse, dann steht dort etwas von einer NullReference in einer Zeile, die auf ein Modul dritter verweist; genaugenommen "Gl.glGenFramebuffersEXT( .. )" aus dem .dll-Modul Tao.OpenGL.

Ich habe im gesamten Projekt keinerlei vom Kompiliermodus abhängigen Code und vor einiger Zeit war das Problem (ohne Wechsel oder Update der zugrundeliegenden Module) noch nicht existent.
Was in diesem Zusammenhang vielleicht etwas interessant ist: Wenn ich die im bin/Debug-Ordner befindliche .exe manuell starte läuft sie mit FPSzahlen, die nach einer im Releasemode kompilierten Version aussehen. Ich verstehe das nicht - der Ausgabepfad für die Releaseversion ist eindeutig der bin/Release-Ordner!
Fetze Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 65
Erhaltene Danke: 1



BeitragVerfasst: Mo 25.02.08 19:11 
Weiß niemand Rat? Das Problem besteht immernoch und ich finde seine Ursache einfach nicht.

Wenn ich ein neues Projekt erstelle, dieselben Module als Referenzen hinzufüge (Als .dll-Referenz, nicht als Projektreferenz) und äquivalenten Code ausführe, läuft alles auch nach "Projekt erstellen" im /bin/release-Ordner ohne Probleme.

Wenn ich bei dem "Problemprojekt" einfach die .exe aus dem bin/Debug-Verzeichnis in /bin/Release kopiere (sonst nichts!), dann läuft es dort auch einwandfrei, obwohl ich sowohl /debug als auch /release frisch kompiliert habe, den gleichen Code verwende und keine Compilerdirektiven verwende.

Ich habe sogar schon die Projektdateien mit dem Texteditor verglichen, ohne eine Anomalie festzustellen.. ich bin mittlerweile völlig ratlos.. ôo
maro158
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 35



BeitragVerfasst: Mo 25.02.08 20:37 
Die .vshost-Dateien sind völlig harmlos. Sie gehören zum sog. Visual Studio hosting process und sind u.a. dazu da, um das Ausführen der Anwendung aus Visual Studio heraus zu beschleunigen. Diese Dateien gibt es erst sein Visual Studio 2005.

- Was passiert denn, wenn Du die Release-Version in den Debug-Ordner kopierst und ausführst?
- Oft sind falsche Pfadangaben im Code die Quelle von Release-Crashes. Hast Du das üperprüft? Wird an die 3rd party dll ein Pfad zu einer nicht existierenden Datei übergeben?
Fetze Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 65
Erhaltene Danke: 1



BeitragVerfasst: Di 26.02.08 07:45 
Die Release-Version funktioniert im Debug-Ordner einwandfrei (Kopiert habe ich nur die .exe). Das finde ich jetzt mal insofern irritierend, weil auch die Debugversion im Release-Ordner einwandfrei funktioniert?! o_O

Ich habe einen Verweis / eine Referenz auf Tao.OpenGL, ansonsten nichts (Die für Tao nötigen .dlls werden via hinzugefügten Elementen mit ins Ausgabeverzeichnis kopiert). Der Absturz basiert auch auf einer Zeile, in der ich einen Tao.OpenGL-Befehl ausführe - jedoch wurden zuvor bereits viele andere Befehle von Tao.OpenGL reibungslos ausgeführt (zumindest ohne Fehler)?
maro158
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 35



BeitragVerfasst: Di 26.02.08 10:27 
Hmmm... Wenn ein Vergleich der Unterverzeichnisse und Dateien in den Ordnern Debug/Release keinen nennenswerten Unterschied zu Tage gebracht hat, könntest Du mal versuchen, alle Release-Dateien und -Ordner ins Debug-Verzeichnis zu kopieren. Wenn's dann auch noch tut, solltest Du die Ordner weiter oben in der Hierarchie untersuchen. Jedenfalls führt kein Weg an eine Differentialdiagnose vorbei.
Fetze Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 65
Erhaltene Danke: 1



BeitragVerfasst: Di 26.02.08 15:35 
Ich hab mal ein wenig weiter getestet und Dateien geprüft, kann mir aber immernoch keinen Reim drauf machen.

Nochmal eine Übersicht der Kopier-Experimente:
- Debug .exe: Geht
- Release .exe: Geht nicht
- Debug .exe in Release: Geht
- Release .exe in Debug: Geht
- Debug "Alles außer .exe" in Release: Geht
- Release "Alles außer .exe" in Debug: Geht

Ein automatisierter Vergleich der Ordner Debug und Release ergab folgendes:
user defined image

Daraus, dass die Release .exe in jedem Zusammenhang funktioniert, solange man sie mit den Debugdaten in Verbindung bringt, schlussfolgere ich, dass nicht das Testprojekt selbst sondern eines der Referenzprojekte beim Kompilieren mist baut. Was aber nicht klärt, warum, weil ich ja wie gesagt keine Compilerdirektiven verwendet habe. :?

Eine Frage: Wäre es möglich, dass VC#2005 einige Compilerdaten oder precompilerdaten noch irgendwo im Cache liegen hat und seit einem - beispielsweise - Absturz des Systems nicht mehr aktualisiert? Das wäre zumindest eine Mögliche Erklärung dafür, warum ein kleiner Teil des Codes plötzlich (und nur im Releasemode) nicht mehr funktionieren will.


EDIT: Ich habe durch weitere Copy-Experimente die Problemdatei lokalisieren können: Fetze.ZweiDe.dll, eines der Referenzprojekte, das direkt eingebunden wird und sich mit in derselben Projektmappe befindet. Das bringt mich allerdings der Lösung nicht direkt weiter, da ich nach wie vor die Ursache des Problems weder sehe noch dementsprechend beheben kann. :/
Ideen?