Ahoi tla75,

krass, das ganze ist über 3 Jahre alt und ich habe weder damit noch mit C# fast 3 Jahre nichts mehr gemacht! Freut mich, dass du meinen Code weiterverwenden konntest, dann war es doch nicht ganz umsonst, dass ich es damals hier gepostet habe!

Viele Grüße
andrgrau

Hallo dN!3L,

danke für den Link! Mit dem AppDomain.AssemblyResolve und AppDomain.ReflectionOnlyAssemblyResolve habe ich es auch schon ein Mal versucht, aber dieses Event wird bei mir dann nie ausgelöst.

Da ich wegen .NETZ keinen Debugger benutzen kann, ist mein Code jetzt voller Logging-Aufurfe und ich habe zum einen das AssemblyLoad Event abonniert und dort sehe ich, dass das Event zuerst von der DLL ausgelöst wird und danach erst von der EXE. Kann es vielleicht daran liegen?

Ansonsten habe ich mir ganz am Anfang mit AppDomain.CurrentDomain.GetAssemblies alle Assemblies holen lassen, die (laut Beschreibung) geladen wurden und da tauchen bereits sowohl EXE als auch DLL auf.

Was ist denn nun wann und wie geladen?! Irgendwie komme ich da nicht mehr hinterher.

Hallo zusammen,

ich verwende .NETZ, um meine EXE mit einer DLL zu packen und dabei bekomme ich eine TypeLoadException. Ich lasse beim Start die app.resources von .NETZ durchlaufen (dort sind die gepackten DLLs drin), lade die Assembly (DLL) mit der statischen Methode GetAssemblyByName von .NETZ und wenn ich dann bei dieser Assembly die Methode GetTypes() aufrufe, wird die Exception geworfen.

Ich sollte noch erwähnen, dass eine Klasse in der DLL von einer Klasse in der EXE erbt und genau diese Klasse macht wohl Probleme:

System.TypeLoadException: Could not load type 'MyClass' from assembly 'MyProgram, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Vielleicht weiß jemand Rat, ich glaube nicht, dass es prinzipiell an .NETZ liegt, sondern eher an der Konstellation, deswegen will ich auch noch nicht den Autor damit nerven. Ein Forum von/für .NETZ gibt es leider auch nicht. Deswegen schreibe ich ja hier 😉

mfg

PS: Prinzipiell geht es um dieses Vorgehen, das ich als Snippet gepostet habe, eben nur mit dem Unterschied, dass ich von einer Klasse in der EXE erbe.

Naja, ist ja nicht wirklich gedoppelt:
...
also es kommt ja kein Feld hinzu.

Stimmt, da hast du Recht, das macht ja auch Sinn. Manchmal sollte ich nicht so kompliziert denken 😉

@herbivore
Wow, danke für deine Code-Skizze. Die Idee finde ich nicht schlecht, wobei ich wahrscheinlich aus "Bequemlichkeit" wahrscheinlich doch die Doppelung nehme, zumindest erstmal.
Falls ich später noch Zeit habe, übernehme ich deinen Vorschlag und vielleicht findet es dann auch seinen Weg in die Snippets bzw. hier rein.

Danke euch beiden.

Hallo ErfinderDesRades,

ich kann die DataSource schon erweitern, aber ich hatte gehofft, dass ich da herum komme. Sonst habe ich ein paar Werte "doppelt", aber wenn es nicht anders geht, dann wird mir nichts übrig bleiben.

Trotzdem vielen Dank für deine Antwort 🙂

Hallo zusammen,

ich habe eine DataSource, die an eine ComboBox gebunden ist. Auf einige Controls (TextBox, Buttons, ...) habe ich ein DataBinding gemacht, das funktioniert auch alles wunderbar, eine super Sache.

Das Problem ist jetzt nur, dass ich bei einem Button das Enabled Feld auf false setzen sollen, wenn in meiner DataSource ein Property auf true ist. D.h. ich müsste es irgendwie invertieren, habe es schon über "Custom Format" versucht, aber da komme ich nicht weiter.

Gibt es da irgendeine Möglichkeit, ganz einfach ein bool Wert beim DataBinding zu invertieren?

Gruß und Danke!

(Ich hoffe einfach mal, das ist irgendwie halbwegs verständlich rübergekommen.)

Hallo Ares,

ich weiß nicht, ob ich dich richtig verstanden habe, aber ich habe vor kruzem diesen Artikel bei codeproject gelesen, wo ein Wizard erstellt wurde. Um die einzelnen "Seiten" darzustellen, hat er auch ein TabControl verwendet. Vielleicht hilft dir das ja irgendwie weiter.

Gruß

Hallo herbivore,

da es 6 Tabs sind und alle recht verschieden sind, komme ich auf einiges an Funktionalität in der GUI. Es gibt einige Events in jedem Tab (aufgrund der Controls in den Tabs) und viele Daten, die ich dann eben an die eigentliche Logik weitergebe, das habe voneinander getrennt.

Danke und Gruß!

Hallo herbivore,

prinzipiell spricht nichts dagegen, bisher habe ich es auch so, ich sehe nur ein Problem darin, dass die UserControl Klasse dann sehr groß wird und wahrscheinlich unübersichtlich.

Um es ein bisschen übersichtlicher zu machen, versuche ich mit #region die "LogiK" der einzelnen Tabs voneinander zu trennen, dass man sich in der Klasse noch zurecht findet.

Eine "Alternative" wäre u.U. noch, dass ich jedes Tab ein UserControl einbinde, aber das bläht ja alles nur noch weiter auf, oder?

Danke und Gruß!

Hallo zusammen,

ich habe eine grundsätzliche Frage zur Herangehensweise bei der Entwicklung meiner GUI. Ich habe meine Form, in diese Form wird ein UserControl aus einer DLL geladen. Die DLL ändert sich bzw. wird dynamisch geladen ala Plugin.
Das UserControl ist fest vorgegeben, es besteht aus einem SplitContainer, wo im linken Bereich Buttons sind und im rechten Bereich ein TabControl mit immer 6 Tabs. Jeder Tab ist für eine ganz bestimmte Aufgabe vorgesehen, aber die Anzahl an Elementen darin kenn ich nicht, die werden später von anderen Entwicklern implementiert.

Sollte ich für jedes Tab eine eigene Klasse anlegen, die von TabPage erbt, so dass ich dort die jeweils spezifischen Methoden/Events/... vorgeben kann, die dort mit ziemlicher Sicherheit benötigt werden? Das macht ja wahrscheinlich am meisten Sinn, da dann die einzelnen Tabs voneinander abgeschottet sind und der Code nachher auch besser lesbar ist.
Meine UserControl Klasse übernimmt dann die eigentliche Koordination zwischen den Tabs, falls dort Daten zwischen den einzelnen Tabs ausgetauscht werden müssen.

Oder gibt es eine bessere Lösung dafür? Es muss später halt möglich sein, dass ein Entwickler einer DLL im Designer seine Controls und ggf. Logik ohne Probleme hinzufügen kann.

Ich hoffe, ich konnte das halbwegs verständlich erklären 😉

Danke und Gruß!

So, meine Lösung habe ich nun in den Snippets gepostet: .Netz gepackte DLLs dynamisch laden - wie "Plugins"

Somit ist dieses Thema für mich gelöst 😉

Beschreibung:

Ich hatte ein Problem, das ich auch hier geschildert habe .Netz gepackte EXE: dll dynamisch laden. Ich hab mir nun dazu meine eigene Lösung gebaut 🙂
Kurz gesagt geht es darum, dass ich DLL Dateien ("Plugins") zusammen mit einer EXE mittels .Netz gepackt habe und die DLL Dateien dynamisch laden möchte. Dynamisch deswegen, weil man nicht weiß, ob und welche DLL Dateien mit gepackt wurden, also der Name unbekannt ist. Wenn DLL Dateien im selben Ordner liegen, kann man den Ordner danach durchsuchen, aber wenn sie mit .Netz gepackt wurden, dann geht das ja nicht. .Netz packt die einzelnen Assemblies als Resource in die EXE mit rein, so dass man gar nicht so einfach darauf zugreifen kann, wie man das gerne hätte. Schaut man sich die EXE mit dem Reflector an, so gibt es nur eine Klasse - den NetzStarter.
Es ist darauf zu achten, dass .Netz mit dem Parameter "-d" für jede DLL aufgerufen wird, die so geladen werden soll.

Meine Vorgehenweise, mit der ich es gelöst habe, ist dabei die folgende:1.Es wird überprüft, ob es sich überhaupt um eine EXE handelt, die mit .Netz gepackt wurde, da wir uns ja keine unnötge Arbeit machen wollen 😉

1.Wenn die EXE mit .Netz gepackt wurde, holen wir uns einen Stream auf die Resource des "EntryAssembly's", mit dem wir dann die Resource lesen können. 1.Wir holen uns die Methode "GetAssemblyByName" vom NetzStarter. Diese Methode gibt uns die Assembly zurück, die zu einem bestimmten Namen gehört, also aus den Resourcen und auch gleich entpackt (unzipped). 1.Wir iterieren über jede Resource, rufen die GetAssemblyByName Methode dabei für jeden Namen auf und erhalten dann ein Objekt vom Typ Assembly. 1.Es wird überprüft, ob es sich um eine Assembly handelt, die wir auch wirklich haben wollen. Dabei wird geprüft, ob es einen Type in dem Assembly gibt, der von einem bestimmten Interface erbt. Wenn dies der Fall ist, holen wir uns eine Instanz von dem Interface bzw. der erbenden Klasse aus dem Assembly und fügen es einer Liste hinzu. 1.Nach Durchlauf von allen Assemblies geben wir die gesamte Liste zurück.

Im angehängten Projekt ist meine gesamte Klasse enthalten, die sowohl nach DLL Dateien im gleichen Ordner sucht und in der EXE, falls sie mit .Netz gepackt wurde.

Anmerkung:
Das ist das erste, was ich hier poste, ich habe es nach meinem besten Wissen gemacht und hoffe, dass es der eine oder andere verwenden kann. Ich bin für jedes Feedback offen, sowohl Lob als auch Kritik, das gleiche gilt natürlch auch für Fragen zum Quellcode 🙂

Quellen/Anregungen:*Using NetZ with Dynamically Loaded Assemblies von Marc Clifton *Plug-ins in C# von Redth *.Netz selber natürlich 😉 *Reflector

        /// <summary>
        /// Searches in the assembly's resources for possible Plugins which a included with the -d option from .Netz.
        /// (If the exe itself was not packed with .Netz, the resources will not be scanned.)
        /// </summary>
        /// <param name="listPlugins">List of all IPlugins. (New ones to be added to.)</param>
        static void SearchNetzPlugins(List<IPlugin> listPlugins)
        {
            // Get the FriendlyName and replace .vshost with an empty String.
            string appName = AppDomain.CurrentDomain.FriendlyName;
            appName = appName.Replace(".vshost", String.Empty); // -> .vshost is used for debugging and leads to a failure when calling Type.GetType!

            // Cut everything behind the last ".", e.g. ".exe"
            int pos = appName.LastIndexOf(".");
            if (pos != -1)
                appName = appName.Substring(0, pos);

            Type type = null;
            try
            {
                // Now we're able to (try to) get the "netz.NetzStarter" Type
                type = Type.GetType("netz.NetzStarter, " + appName);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.StackTrace);
                return;
            }


            // type will be not null if the application was started from the netzloader
            if (type != null)
            {
                Stream stream = null;
                try
                {
                    // Get resource's stream from the entry assembly (which is the netzloader)
                    stream = Assembly.GetEntryAssembly().GetManifestResourceStream("app.resources");
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.StackTrace);
                    return;
                }

                // If there is a stream
                if (stream != null)
                {
                    // Get the "GetAssemblyByName" method from .Netz which can be called later to get an assembly out of the resources
                    MethodInfo getAssemblyByNameMethod = type.GetMethod("GetAssemblyByName", BindingFlags.NonPublic | BindingFlags.Static);

                    // Create a resource reader to read from the stream
                    ResourceReader resReader = new ResourceReader(stream);
                    // Get the enum of the resources
                    IDictionaryEnumerator resEnum = resReader.GetEnumerator();

                    // Iterate over every resource's enum
                    while (resEnum.MoveNext())
                    {
                        // zip.dll must be excluded as it can't be unpacked
                        if (resEnum.Key.ToString().Equals("zip.dll"))
                            continue;

                        Assembly pluginAssembly = null;
                        try
                        {
                            // Invoke the "GetAssemblyByName" method from netz and give it the resource's key as parameter
                            pluginAssembly = (Assembly)getAssemblyByNameMethod.Invoke(null, new object[] { resEnum.Key.ToString() });
                        }
                        catch (Exception ex)
                        {
                            Console.WriteLine(ex.StackTrace);
                            continue;
                        }

                        // If there is an assembly
                        if (pluginAssembly != null)
                        {
                            // Get an instance of the Interface (if it's a Plugin)
                            IPlugin plugin = IsPluginAssembly(pluginAssembly);

                            // If it's a Plugin then add it to the list of all possible Plugins
                            if (plugin != null)
                            {
                                listPlugins.Add(plugin);
                            }
                        }
                    }
                }
            }
        }

Schlagwörter: .Netz Dynamically Loaded Assemblies Assembly Plugin DLL Resource NetzLoader

Wenn Du fertig bist, ich könnte das auch gebrauchen 😉

Bis Montag sollte es fertig sein, ich werds dann auch in die Snippets posten 😉

Gibt auf Codeproject ( wie immer ) ein Lib zu Netz, wo Marc Cliffton

Den Artikel habe ich auch schon gelesen, bin auch dabei Teile davon umzusetzen in Verbindung mit dem Code von .Netz selber, den ich per Reflector mir angeschaut habe.
Korrigier mich, wenn ich falsch liege, aber das von ihm bereitgestellte Code liefert mir ja nicht alle Assemblies, die durch .Netz mir verpackt wurden, oder?

Momentan versuche ich es folgendermaßen: (Bzw. heute wahrscheinilch nicht mehr)
Wie Marc Cliffton überprüfe ich, ob die Applikation vom .Netz Loader gestartet wurde, dann hole ich mir mit Assembly.GetEntryAssembly().GetManifestResourceStream("app.resources") den Stream für die Resources. Übergebe den Stream einem ResourceReader und somit kann ich auf die Resourcen zugreifen bzw. durchlaufen. Dort stehen dann alle meine Resourcen drin (inkl. der Tests), lass mir vom NetzStarter die eigentliche Assembly zurückgeben und überprüfe die dann eben wie normale DLL Dateien.

Hallo zusammen,

ein neuer Beitrag in Bezug auf ein anderes Thema von mir (Entwurf eines eigenen Frameworks).
Ich habe eine EXE und ein paar DLL Dateien, die mit dem Tool .Netz zu einer EXE gepackt werden. Die EXE weiß nicht, ob und wie viele DLL Dateien vorhanden sind, da es sich bei den DLLs um Module/Plugins handelt.

Zum Testen ohne .Netz durchsuche ich einfach im im gleichen Ordner der EXE, ob DLL Dateien vorhanden sind, lade diese (Assembly.LoadFrom), überprüfe auf ein Interface (stellt sicher, dass es eine korrektes Plugin ist) und wenn das passt, dann erstelle ich mir eine Instanz und kann das Plugin laden.
Das funktioniert wunderbar, ich suche nun eben noch nach einer Möglichkeit, das gleiche zu machen, wenn die DLL Dateien mit .Netz gepackt wurden.

mfg

Ok, ich muss jetzt doch noch einmal schreiben, da sich leider noch ein Problem aufgetan hat:
Es soll immer nur eine EXE sein, d.h. die Test-DLL soll in der EXE entahlten sein. Das erledige ich über .Netz und das funktioniert an sich ja auch über den -d Parameter, dass ich DLLs mit Assembly.Load("test.dll") laden kann. Das Problem ist nur, dass ich dann die DLLs nicht mehr suchen kann, wie wenn sie im selben Ordner liegen würden. Da die DLLs nicht alle immer gleich heißen sollen, sondern ich zur Laufzeit rausfinden will, welche der Test ist (Prüfen, ob von Interface geerbt).

Konkret ist dazu die Frage, ob es eine Möglichkeit gibt, nach DLLs zu suchen, die mit in die EXE gepackt wurden? Ich hab schon rumgesucht, bisher aber noch nichts dazu gefunden.

mfg

Hallo JuyJuka,

danke für deine Antwort, als ich noch ein bisschen rumgespielt hab und auch den Artikel Plug-ins in C# auf Codeproject gelesen habe, kam mir das dann auch, dass ich noch ein Interface einbau, um zu testen, ob diese davon erben. War an sich eh schon geplant und jetzt habe ich noch einen Grund mehr, das so einzubauen.

Ich werde auf jeden Fall versuchen, dass auch im Test UI und BL getrennt bleiben, zumindest werde ich es so zur Verfügung stellen und hoffen, dass die späteren Test-Entwickler es auch einhalten 😉

Vielen Dank für eure Hilfe!!!

Nachdem ich nun ein bisschen rumprobiert habe, habe ich mich jetzt (hoffentlich^^) endgültig für folgendes Szenario:

Das Framework ist die ausführbare EXE, die die gesamte "Logik" enthält, auf die ein Test zurückgreift. Außerdem ist dort auch das Form mit Menu etc.
Jeder Test ist eine DLL, der prinzipiell aus mind. einer UserControl besteht, die dann eben von der EXE geladen und dargestellt wird.
Es soll sich immer um nur eine EXE handeln, d.h. ich verwende das von JuyJuka vorgeschlagene Tool .Netz, um aus einer EXE und eine DLL nur eine EXE zu bekommen, wo alles enthalten ist. (.Net ist immer installiert!)

Da die EXE (das Framework) nicht weiß, welcher Test ihm beiliegt, muss ich die DLLs dynamisch laden. Aus diesem Grund sollte jeder Test immer gleich heißen, also "test.dll" zum Beispiel.
Reicht das dann aus, dass ich per Assembly.Load("test.dll") die DLL lade und eben verwende? (Hier gibts ja einige Artikel dazu, deswegen die Frgae zum prinzipiellen Vorgehen.)

mfg

Hallo herbivore,

ich geb dir ja auch Recht, dass die Template Methode nicht gut ist, wobei ich mir noch ein paar weitere Gedanken gemacht habe und mir einen Mittelweg dazu überlegt habe:
Ich packe den gesamten BL und DAL in das Framework und erstelle daraus eine DLL, die dann wiederum vom Test-Projekt benutzt wird. Das Test-Projekt lege ich in diesem Fall jedoch als Template an, so dass spätere Test-Entwickler hier ein gewisses Grundlayout haben, das sie benutzen müssen/sollen.

Nochmal auf meinen ersten Post bezogen:*Macht es Sinn (wie im angehängten Bild beschrieben), das Projekt so in Ordnern aufzuteilen? Dann habe ich kein heilloses Durcheinander mit den Klassen. *Logging: Sinnvoll nur wegen Logging AOP zu benutzen oder einfach log4net o.ä. benutzen?

mfg

Hallo JuyJuka,

danke für die Begrüßung auf mycsharp.de 🙂

Die GUI kann man (im einfachsten fall) als UserControl implementieren, welches von der eigentlichen Form (aus dem Basis-Projekt) geladen und angezeigt wird.

Das könnte dann z.B. folgendermaßen aussehen: Ich implementiere mein gesamtes Framework mit allem, erstelle daraus dann eine exe/dll. Diese wird dann von dem eigentlichen Test-Projekt als Referenz hinzugefügt und kann somit ohne Probleme darauf zugreifen. Soweit alles klar.
In meinem Framework erstelle ich das Grundgerüst der GUI (Fenster, Menu, ...) und im Test-Projekt ist dann der Rest der Oberfläche als UserControl? D.h. ich würde aus dem Test-Projekt, das der Einstiegspunkt ist, die Form aus dem Framework starten und dann das UserControl dem Form hinzufügen?

Nur damit ich das richtig verstehe, bei GUI Design bin ich bisher weniger erfahren.

Zu meinem bisherigen Ansatz: Nicht dass das falsch verstanden wird, es soll zwar schon möglichst schön sein, jedoch muss ich aufgrund meiner fehlenden Erfahrungen bei solch einem Design einen Mittelweg finden, mit dem ich das Projekt in der vorgegebenen Zeit abliefern kann und später auch damit gearbeitet werden kann.
Zwar mag das Template nicht wirklich schön sein, ist aber bisher der bequemste Weg dafür, m.E. nach. Die eigentliche Hauptaufgabe an Programmieraufwand kommt ja eigentlich noch, die ganzen Funktionalitäten, die ich bereitstellen muss (wie oben erwähnt).

mfg

Hallo herbivore,

danke für deine Antwort.
Ich weiß, dass diese Lösung bei weitem nicht die schönste ist, das Problem an der ganzen Sache ist jedoch, dass jede einzelne Test-Applikation sehr spezifisch ist. Bei der einen werden nur ein par Werte eingestellt, Tests durchlaufen und am Ende kommt eine Textdatei als "Ergebnis" raus. Bei einer anderen müssen verschiedene Graphen erstellt werden (teils über externe Programme), Test-Ergebnisse im der GUI dargestellt werden und im schlimmsten Fall noch ActiveX-Forms eingebunden werden, die exakt für dieses Gerät entwickelt wurden.
Die Leute, die später auf der Basis Tests-Applikationen entwickeln, sind größtenteils aus der Elektrotechnik, also haben wenig Erfahrung bei Softwareentwicklung und mögen es am liebsten ganz einfach haben: Visual Studio zum Erstellen der GUI.
Deswegen auch ein Template, so dass sie VS starten und anstatt eines leeren Projekts legen sie meine Vorlage an, die schon die wichtigsten Dinge bereithält.

Ich hoffe, das macht es etwas klarer, warum ich mich dafür entschieden habe.

Hallo zusammen,

ich bin neu in der C#/.NET Programmierung, komme bisher eher aus der reinen C-Welt und Java und muss mich nun berufsbedingt mit C#/.NET beschäftigen.

Kurze Projektbeschreibung:
Als erstes kurz was ich genau machen möchte/soll: Ich soll eine Art Framework erstellen, so dass später auf Grundlage von diesem Framework weitere Programme entwickelt werden können. Es handelt sich dabei um Programme, die ein bestimmtes Messgerät ansprechen, auf dem Tests ausgeführt werden und Ergebnisse zurückgeliefert werden. Ich selber muss keinen dieser Tests implementieren, ich stell nur das Rahmenwerk, das dafür notwendig ist, dass nicht jedes mal das Rad neu erfundenn werden muss - was bisher der Fall war. D.h. es werden später andere dransitzen und die jeweilige Test-spezifische Logik programmieren.

Überlegungen
Es wurde entschieden, dass eine Vorlage in Visual Studio 2005 erstellt wird, die alle benötigten Funktionalitäten bereitstellt und darin dann die eigentliche Test-Logik hinzugefügt wird und die GUI dementsprechend angepasst wird. Der Grund hierfür liegt v.a. daran, dass die späteren Test-Entwickler so alles in einer Solution haben, sich ihre GUI zusammenbauen können und "möglichst komfortabel" entwickeln können. Außerdem soll jeder Test-Applikation nur aus einer exe bestehen.
(Es stand auch noch zur Auswahl die Funktionen als DLL bereitzustellen, die vom eigentlichen Test eingebunden wird, da aber die GUI einige Elemente besitzt, die immer dabei sein müssen und nicht vergessen werden dürfen, wurde diese Idee verworfen. Außerdem war noch die Idee, dass Test-Programme Module/Plugins sind, die geladen werden. Dort war jedoch das Problem mit der GUI, da diese einfach zu designen sein sollte und es hätte vermutlich den zeitlichen Rahmen gesprengt, da dort noch keine Erfahrungen vorhanden sind.)

Architektur
Nachdem ich einige Tage im Internet recherchiert habe, v.a. auch hier im Forum, habe ich mir eine 3-Schichten Architektur überlegt:*Presentation Layer: Das Grundgerüst der GUI mit allen wichtigen Elementen, die immer vorhanden sein müssen. Diese kann dann in Hinblick auf den jeweiligen Test einfach erweitert werden. *Business Layer: Hier steckt die gesamte Logik drin, d.h. zum einen ein Interface für die Test-Logik, das später realisiert wird. Außerdem steckt hier die gesamte Logik "drumherum" drin, also Verbindungsauaufbau zum Geräte, kleine "Tools" wie Interpolation etc., ein Mechanismus zur Lizenszierung, Erstellung von Test-Reports. *Data Access Layer: Speicherung der Daten, v.a. in Form eines Projekts, in dem Test-Ergebnisse, Einstellungen und der Report gespeichert werden.

Fragen
Nach langer Vorarbeit nun zu meinen Fragen, ich hab ja auch einen Hintergedanken, warum ich hier schreibe 😉1.Macht meine 3-Schichten Architektur Sinn? Es wäre so, dass die GUI die Test-Logik aufruft und über Events dann informiert wird, wenn neue Ergebnisse vorliegen. Die Test-Logik (bzw. der gesamte Business Layer) kennt die zugrundeliegenden Daten und kann sie benutzen. Die GUI kann somit nicht direkt auf Daten zugreifen, sondern nur über den Business Layer. 1.In Java kann ich ja vieles über Packages strukturieren, ganz so "nett" erscheinen mir die namespaces nicht. Daher habe ich mit Ordnern eine eigene Aufteilung des Projekts versucht, um Chaos vorzubeugen. (siehe Bild im Anhang) 1.Logging soll auch Bestandteil sein, bei Java habe ich schon Erfahrungen mit AspectJ gemacht, macht es daher Sinn rein für das Logging AOP (z.B. rapier-loomer.NET) zu benutzen oder soll ich dann lieber auf ein Framework ala log4net setzen? (Hoffentlich löst das keine Glaubenskriegen jetzt aus ^^ ) 1.Noch sonstige Anregungen bzw. Hinweise?

Vielen Dank schon einmal für eure Hilfe und Anrgeungen!!!