Laden...

Was spricht gegen AppDomain.CurrentDomain.SetData ("DEBUG", "True") als 'globale Variable'?

Erstellt von AtzeX vor 14 Jahren Letzter Beitrag vor 14 Jahren 2.645 Views
A
AtzeX Themenstarter:in
217 Beiträge seit 2006
vor 14 Jahren
Was spricht gegen AppDomain.CurrentDomain.SetData ("DEBUG", "True") als 'globale Variable'?

Hallo zusammen,

ich überlege, wie ich Assembly-überreifend eine 'globale Variable' erstellen kann.

Der Hintergrund ist der, dass ich in meinem Projekt, welches aus mehreren Assemblies besteht, Code nur ausführen lassen möchte, wenn ich im "Debug"-Modus bin.

Natürlich könnte ich mit der "/DEBUG"-Konstante, bedingter Kompilierung und zwei Sätzen von Assemblies arbeiten, jedoch möchte ich das nicht.
Ich möchte auch im Release meinen 'Debug-Modus' ein- und ausschalten und diesen damit nutzen können.
Hinzu kommt, dass die ein oder andere Assembly gar nicht zum Projekt gehört, sondern als Binary referenziert wird.

Ich habe mir nun folgendes ausgedacht:
In der eigentlichen ausführenden Assembly, also im gegebenen Fall meiner EXE-Datei, habe ich ein Feld

static private bool _debug = false;

hinzugefügt, welches ich z.B. (in diesem Falle exemplarisch fest codiert) mittels einer ebenfalls hier erzeugten AppicationDomain-Property setze:

AppDomain.CurrentDomain.SetData("DEBUG", "True");
_debug = (AppDomain.CurrentDomain.GetData("DEBUG").ToUpper() == "TRUE");

Der Vorteil ist, dass ich in allen meinen Assemblies, welche ich referenziere, nun mit einem Feld wie

static private bool _debug = (String.Format("{0}", AppDomain.CurrentDomain.GetData("DEBUG")).ToUpper() == "TRUE");

diese Property nutzen kann.

Performancetechnisch sollte das kein Engpass sein.

Auch habe ich nicht vor, mehr als eine AppDomain zu verwenden.

Was spricht gegen diesen Ansatz, bzw. was für Alternativen gäbe es?

Gruß,
AtzeX

3.971 Beiträge seit 2006
vor 14 Jahren

AppDomain.CurrentDomain.SetData

ist dafür ungeeignet. Besser wäre beispielsweise eine Setting in der App.Config.

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

A
AtzeX Themenstarter:in
217 Beiträge seit 2006
vor 14 Jahren

Hi, danke für den Reply.

Könntest du mir auch sagen, warum das ungeeignet ist?

Edit:
Was meinerseits gegen eine "App.config" spricht, ist, dass ich meine Anwendung (natürlich je nach Anwendungsfall, aber in diesem ist es so) bis auf Ausnahmen über eine zentrale SQL-Datenbank parametrisiere.

3.971 Beiträge seit 2006
vor 14 Jahren

AppDomain.GetData und SetData ist ungeeignet weil der Wert als Object übergeben wird. Weiterer wichtiger Punkt, .NET verwendet das für interne Zwecke. Es könnte somit passieren, dass du einen anderen Wert mit gleichem Namen überschreibst oder dadurch auch andere ungewollte Seiteneffekte auftreten.

MS hat leider den Fehler gemacht, die zwei Methoden öffentlich zur Verfügung zu stellen. AppDomain-Einstellungen sollten meiner Meinung nach nur beim Erstellen vorgenommen werden können, nicht aber bei existierenden Apps. Fürs komfortable Erstellen gibts die Klasse AppDomainSetup

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

A
AtzeX Themenstarter:in
217 Beiträge seit 2006
vor 14 Jahren

Das ungewollte Überschreiben eines bestehenden Wertes bzw. ungewollte Seiteneffekte kann man ja durch einen etwas außergewöhnlichen Namen umgehen.
Ansonsten spricht jetzt aber wohl nicht wirklich etwas gegen diese Lösung...

Gibt es denn Alternativen (außer der App.Config)?

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

Ansonsten spricht jetzt aber wohl nicht wirklich etwas gegen diese Lösung...

Naja, schon dass der Typ als Object zurückgegeben wird und somit könnte Boxing/Unboxing ein Problem werden zumal das kein guter Stil ist.

Gibt es denn Alternativen (außer der App.Config)?

Wenn du oben geschrieben hast dass über eine Datenbank parametrisiert wird wäre die Datenbank eine Alternative 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

A
AtzeX Themenstarter:in
217 Beiträge seit 2006
vor 14 Jahren

Hi, danke für deine Antwort.

Wenn du oben geschrieben hast dass über eine Datenbank parametrisiert wird wäre die Datenbank eine Alternative 😉

Nicht unbedingt, denn dann müsste ich diese Information, welche ich aus der Datenbank gewonnen habe, an jede noch so kleine Assembly immer 'durchreichen'.

Oder jede Assembly würde selber an die DB connecten, was aber schon vom Anwendungsdesign her wegfällt.

Der Vorteil meines Ansatzes ist ja die 'quasi Automatik', welche zudem Assembly-übergreifend ist.

Bin aber natürlich für Ideen/Vorschläge offen.

Gruß,
AtzeX

3.825 Beiträge seit 2006
vor 14 Jahren

Übergib doch /debug als Parameter an Deine Applikation und schreibe das bei Prgrammstart in die globale Variable _debug.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

A
AtzeX Themenstarter:in
217 Beiträge seit 2006
vor 14 Jahren

Hi, danke auch dir.

Die Variable alleine wäre dann aber nicht über Assembly-Grenzen hinweg verfügbar. 😉

Gruß,
AtzeX

X
1.177 Beiträge seit 2006
vor 14 Jahren

huhu,

Wieso nicht eine Assembly mit eben dem statischen Feld Debug nutzen? Diese referenzierst Du dann in allen anderen Assemblys.

public static class Options
{
  public static bool DebugMode = false;
}

In eine eigene Assembly reinpacken und in jeder anderen Assembly referenzieren

if (Options.DebugMode) ...

Kann man dann wann/wo man will an- und ausschalten.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

A
AtzeX Themenstarter:in
217 Beiträge seit 2006
vor 14 Jahren

Ist zumindest ne Idee.
Ich denke mal drüber nach.

Danke dir!