Hallo "Kollegen",
kann man mit C# (bzw. .NET) feststellen, in welcher Umgebung (Release oder Debug) eine Anwendung gestartet worden ist?
Danke schon mal für etwaige Antworten im Voraus.
Gruß
Hallo mosspower,
#if DEBUG
herbivore
Hierzu stehe ich im Moment vor einem Problem oder besser: vor einer Ungewissheit.
Ich habe im VS2005 eine Projektmappe mit mehreren Projekten. In den einzelnen Projekten brauche ich an gewissen Stellen sowas:
#if DEBUG
... mach irgendwas ...
#endif
Jetzt habe ich mir gedacht, dass ich in einer statischen Basisklasse ("ganz unten") eine Methode definiere:
public static bool IsDebugEnvironment()
{
bool isDebug = false;
#if DEBUG
isDebug = true;
#endif
return isDebug;
}
und diese Methode in allen darauf aufbauenden Projekten verwende, anstatt dort jedesmal "#if DEBUG" abzufragen.
Nun habe ich das getestet und es scheint auch so, dass das richtig funktionert. Ich habe sogar ein Release-Build der Basisklasse als Verweis eingebunden und denn in der Debug-Konfiguration das Programm gestartet. Ergebnis: Die Konfiguration des Programms ("Debug") schlägt anscheinend bis in die von ihm eingebundenen Assemblies (Release-Builds) durch.
Ich bin mir aber nicht schlüssig, ob dies wirklich ein kugelsicherer Weg ist.
Ich wüsste nicht was dagegen sprechen sollte.
Ich würds aber so machen:
public static bool IsDebugEnvironment {
get {
#if DEBUG
return true;
#else
return false;
#endif
}
}
Das find ich übersichtlicher und außerdem sparst du dir eine unnötige Variable.
@rastalt: Nimm's bitte nicht persönlich aber ich hasse mehrere Returns in einer Methode. Deswegen kodiere ich so nicht.
Ob man, wie in diesem Beispiel, den ELSE-Fall ausprogrammiert oder schon vor dem IF eine Variable setzt ist wieder ein anderes Thema und hat mit meiner Multi-Return-Aversion nichts zu tun.
Das sehe ich eigentlich auch so, retnug. Aber in diesem Fall wird ja beim Kompilieren nur einer von beiden Fällen auch wirklich mit ins eigentliche Programm übernommen. Da die Methode ja auch nicht so komplex ist, würde ich es in diesem Fall okay finden. Aber ist halt Geschmackssache. 🙂
Hallo retnug,
mir ist nicht klar, warum du
if (IsDebugEnvironment) [
besser findest als
#if DEBUG
Zumal das obere zu unnötigem Code führt, erst zur Laufzeit ausgewertet wird und unnötigerweise schwerer zu lesen und zu verstehen ist. Ich halte das für eine, sorry, Schnapsidee.
herbivore
Diese Methode soll nicht dazu dienen, Code bedingt zu kompilieren. Mit Hilfe der Feststellung der Konfiguration zur Laufzeit und mit weiteren, noch zu implementierenden, Abhängigkeiten soll letztendlich zurückgegeben werden, ob man quasi in einem logischen Test- oder Produktiv-Zustand arbeitet.
Z. B.:*Die Anwender sollen eine Warnung bekommen, wenn sie irrtümlich mit einer Debug-Konfiguration arbeiten. *Die Anwender sollen eine Warnung bekommen, wenn der Applikationsserver irrtümlich mit der Testdatenbank verbunden ist. *Die Entwickler sollen eine Warnung bekommen, wenn der Applikationsserver mit der Produktivdatenbank verbunden ist.
auch wenn schon gelöst ist
pragmas soll man laut MS sowiso nicht mehr benutzen. Dafür gibts nun das Conditional-Attribute
Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei denen es darum geht, wer den cooleren, imaginaeren Freund hat
Hallo retnug,
wenn du einen logischen Test- oder Produktiv-Zustand abfragen willst, müsstest du aber die IsDebugEnvironment-Methode auch anders implementieren. Wenn du sie so implementiert lässt, wie sie oben ist, dann behalte ich meinen Einwand aufrecht.
herbivore