[gelöst] Assembly enhancen und dynamisch laden...?

Hallo Leute!

Ich möchte ein Assembly von mir Kundenspezifisch erweitern. Wie genau das funktionieren soll ist noch nicht klar, was passieren soll schon:
Es soll möglich sein ohne Einschränkungen Klassen, Felder, Properties und Methoden hinzuzufügen - spiele diesbezüglich grade mit PostSharp - Soll das ja so oder ähnlich können.
Unumgehbar ist allerdings, dass sich der gesamte Klassenbaum in einem Assembly befindet… 😦

Das entgeltliche Problem ist aber dann das Assembly wieder zu laden. In meiner Projektmappe gibt es also diese dll und einige Projekte mit Verweisen darauf. Nun ist es möglich, dass ein Kunde mehrere Erweiterungen braucht die nichts miteinander zu tun haben.
Also wird das Programm mehrfach gestartet und je nach dem wird mal die eine erweiterte DLL und mal die andere geladen. Sie liegen beide im Programmverzeichnis - aber eben mit unterschiedlichem File-Namen und die Original-DLL gibt es nicht mehr.
Dann kann ich also das Assembly laden, aber wie sage ich nun meiner Appl, dass es den Verweis ändern soll bzw. geht das überhaupt?

Hatte das ganze hier schon mal diskutiert, allerdings mit anderer Grundidee und falschem Ansatz. Daher habe ich mir erlaubt einen neuen Thread zu starten...

thx

1. Ich verstehe immer noch nicht WARUM.

2. Ein Programm, das sich selbst schreibt ist suspekt und unheimlich

3. Liefere doch den Quellcode und einen Compiler an den Kunden aus, dann kann er es selbst mit allen nötigen Properties und Methoden erstellen.

4. An PostSharp hab ich auch schon gedacht, aber dazu mußt du das komplette Programm neu kompilieren, das hattest du von Anfang an ausgeschlossen, damit es nicht für jeden Kunden eine eigene Version gibt.

5. Warum hast du einen neuen Thread aufgemacht? Das ist doch immernoch das gleiche Problem?

6. Hattest du die naheliegende Frage noch nicht beantwortet, wie das in Delphi, bzw. FastObjects funktioniert.

Schöne Grüße,
Christian

Jetzt klingt es schon viel mehr nach einer regulären Plugin-Architektur.

aber eben mit unterschiedlichem File-Namen und die Original-DLL gibt es nicht mehr.

Du musst doch bei jeder Änderung (unabhängig davon welcher Kunde was braucht) sowieso irgendetwas zusätzlich zum bestehenden Grundsystem ausrollen.
Warum nicht einfach die DLL austauschen oder eine weitere DLL (als Plugin) daneben legen?

Eigentlich brauchst du, so wie sich das für mich anhört, nur eine Host-Applikation und lädst dann GUI sowie Logik einfach in Form von Plugins nach.

Ausgangspunkt hierfür (simpler Ansatz der die Konfiguration und andere Aspekte vernachlässigt) könnte z.B. ein Menü sein in das sich die Plugins eintragen können und aus welchem der Benutzer dann die gewünschte Funktion aufrufen kann.

aber wie sage ich nun meiner Appl, dass es den Verweis ändern soll bzw. geht das überhaupt?

Du referenzierst in deiner Host-Applikation einfach nichts außer deinen Standardkomponenten und lädst nachher alles lose gekoppelt nach. Musst dir halt was überlegen wie die einzelnen Plugins nachher Kommunizieren oder ob sie das überhaupt sollen (sie könnten z.B. auch alle eine eigene Datenbankverbindung unterhalten und autonom arbeiten oder du bietest ein interface für solche Geschichten aus deinem Host an damit du alles in eine Transaktion packen kannst)

[FAQ] Eigene Anwendung pluginfähig machen

Hi!

@MrSparkle

1. Was genau ist daran nicht zu verstehen?

2. Wie schon gesagt - unsere Kunden lieben genau das und wir leben seit Jahren davon

3. Wäre eine Idee - Da ich nur den Code des DB-Schemas liefern müsste wäre das nicht mal das große Problem...

4. Bin ich grad draufgekommen - obwohl es laut herbivore die Funktionen Assemly lesen, ändern und wieder speichern geben soll...
   Bin aber grade noch auf ILMerge gestoßen.

Source mit ausliefern wäre eine Möglichkeit, an die ich auch schon gedacht hatte - wird wohl drauf hinauslaufen... 😦
Um das sauber zu Lösen steht aber dieses Problem noch im Raum

Welche Frage hatte ich nicht beantwortet?

Jetzt klingt es schon viel mehr nach einer regulären Plugin-Architektur.

🙂 Eben meiner Meinung nach nicht - dar ganze Klassenbaum muss in einem Assembly liegen - Da komm ich allem Anschein nach nicht herum - Sonst wär's das ganze ja kein Problem...

thx

Welche Frage hatte ich nicht beantwortet?

z.B. Frage 6 von Mr.Sparkle.

Dann kapier ich es aber auch noch nicht 😉 Wie willst du den Kunden die Anwendung komplett ändern lassen ohne ihm den Source zukommen zu lassen?

Wir hatten hier auch schon mal gescherzt dass wenn der Kunde eine komplett Anpassbare Anwendung haben will (wie unserer das wollte) wir ihm einfach ein VS verkaufen und den Source geben (quasi als Config-File).
In der Regel ist allerdings nicht erwünscht das der Kunde die Sourcen bekommt und da selber dran rumpfuscht. Außerdem wirft das wieder recht komplizierte Fragen auf wie z.B.: wie supportet man sowas?
Und ich kann mir nicht wirklich vorstellen das der Kunde wirklich zufrieden ist wenn man auf einmal das Know-How um an so einer Anwendung rumzubasteln voraussetzt (ganz krass: Dann kann ichs auch selber schreiben).

Bei Plugins hingegen kannst du ja sogar eine SDK für Kundenspezifische Erweiterungen mitliefern...

Wenn du uns wenigstens mal im Ansatz erklären würdest wie das in der anderen Sprache (die ja mit ihren Kompilaten wesentlich unflexibler ist als dies bei Assemblies der Fall ist) gelöst wurde dann findet man evtl. wenigstens eine Annährung.

Ist diese Form der Software denn irgendwo benannt? Gibt es evtl. Patterns die das unterstützen und die wir einfach nicht kennen... Alles so Infos die hier hilfreich wären.

Hallo,

1. Was genau ist daran nicht zu verstehen?

Ich hab' die Anforderungen auch nicht verstanden. Gibt es wirklich keine bessere Lösung?

2. Wie schon gesagt - unsere Kunden lieben genau das und wir leben seit Jahren davon

Warum dann was ändern?

Naja - wie wäre es mit einer Script-Lösung? z. B.
http://www.codeproject.com/KB/cs/cs-script_for_cp.aspx

Übrigens, "enhancen" ist kein schönes Wort...

Hi!

Frage 6 wurde im anderen Thread beantwortet:

In Delphi war es keine OODB... Da gab es keine DB-Klassen im Programm sondern nur dynamische Felder.

Nochmal: Die Anwendung wird nicht vom Kunden, sondern von uns erweitert. Das muss aber beim Kunden vor Ort möglich sein.
Es gibt ein Grundsystem das laufend erweitert wird und darauf aufsetzende Erweiterungen.
Es soll auf nicht 100 Versionen geben (bzw. eine Pro Kunde) die ich bei jeder Änderung am Grundsystem wieder aktualisieren muss...

Warum dann was ändern?

Umstellung von Delphi und DBase auf C# und FastObjects

Übrigens, "enhancen" ist kein schönes Wort...

Steht im Wörterbuch... Stell dir einfach vor da steht erweitern... 🙂

Das Problem der Erweiterung ist, dass ich mein Original-Assembly ändern muss - Es geht nur um den Klassenbaum der DB.

Der Rest der Applikation ist bereits erweiterungsfähig - in Funktion und GUI. Nur dass hier temporär Assemblies erstellt und geladen werden und das eben mit dem DB-Schema nicht möglich ist...

lg

Hallo webbi,
ich kann es dir gerne nochmal sagen, C#, DOT NET und die CLR sind objektorientierte Programmiersprachen bzw. Umgebungen, wo Probleme mit Klassen, Abstraktion und Kapselung gelöst werden. Wenn du damit nicht umgehen kannst, nutze bitte eine andere Programmiersprache und Programmierumgebung.

Um das was du vorhast mit C# umzusetzen, kannst du eine, für deinen Fall entsprechende, Markup-Sprache (auf Basis von Xml) definieren, die zur Laufzeit entsprechende bereits fertige Klassen erstellt und konfiguriert. Auch hier ist Abstraktion und Kapselung enorm wichtig.

Als Beispiel kannst du dir gerne XAML mal anschauen.

Es geht nur um den Klassenbaum der DB

Ahh, das wird doch schon konkreter (evtl. hab ichs in dem anderen Thread überlesen)...

Aber trotzdem: Was spricht dann dagegen es nicht genauso zu machen wie vorher nur das es halt jetzt nicht mehr über Tabellen sonder über Objekte abgebildet wird?
Also eine CDB die alle Standardfälle abdeckt und zusätzlich Feld-Objekte verschiedener Typen die nachher in der Anwendung wieder zusammengemanscht werden?

Wie das dann mit der Performance aussieht (zumal ich mich nur mit O/R-gemappten RDBMS auskenne) steht allerdings wieder auf einem anderen Blatt da du ja unendlich viele Queries brauchst um dir alle benötigten Daten aus der DB zu saugen um daraus verwendbare Objekte zu bauen.

.Net sollte dir dann alles bieten was du brauchst um daraus ein verwendbares in memory Objekt on the fly zusammenzustecken (was dann am besten Plugins erledigen die von den Consultants vor Ort erstellt werden). Stichwort hier: Property descriptoren.
Du hast ja auch die Möglichkeit dir alle benötigten Meta-Daten in die Datenbank zu legen.

Ok, anscheinen schaff ich es nicht mein Problem deutlich genug zu beschreiben oder übersehe etwas. Auf jeden Fall reden wir etwas an einander vorbei…

Ich werde das ganze mal so bauen, dass der Source des DB-Baums komplett mit ausgeliefert wird und dann beim Kunden nach jedem Update oder Erweiterung neu kompiliert und überschreibe einfach meine Original-DLL…

@kleines_eichhoernchen
Wir haben uns aus diversen Gründen für FastObjects entschieden. Ein Runtime dafür gibt es für C++, Java und C#.
Da C++ und Java wiederum aus diversen anderen Gründen ausscheiden muss ich es in C# hinbekommen...

thx

Also hab ich es jetzt doch nicht gerafft heul

Du hattest vorher sowas:

• Tabelle mit Strings
• Tabelle mit Zahlen
• Tabelle mit Datum
• usw...

Wenn du nun ein Objekt benötigt hast dann hat du es einfach aus den verschiedenen Felder zusammengebaut.

???

Wenn das so war dann kannst du das doch trotzdem abbilden.

@jaensen - Wenn ich dich richtig verstehe:

In Delphi gab es keine DB-Objekte, und keinen O/R-Mapper:

  AdressTable.Append();
  AdressTable["Name1"].AsString = "Vorname";
  AdressTable["Name2"].AsString = "Nachname";
  AdressTable.Post();

In CSharp;

  Adresse adr = new Adresse();
  adr.Name1 = "Vorname";
  adr.Name2 = "Nachname";
  adr.Store();

Schema der DB und Schema im Programm MÜSSEN beim laden der DB 100% übereinstimmen - Sonnst spinnt FastObjects.
Und das Schema muss in einem Assembly liegen - Sonnst spinnt FastObject.

lg

Na und.

Du kannst dir dein Datenmodell ja so bauen das du jeweils einen eigenen Objekttypen für jede Art von Feld welches du brauchst hast (Metadaten).
Das wären dann z.B. Varchars, DateTimes, Ints, Bools usw.

Diese linkst du an ein definitions-objekt (Metadaten) welches zur Laufzeit abgefragt wird.

Dieses Definitionsobjekt agiert dann als Template für alle konkreten Instanzen des Objekts ebenso wie die Feld-Definitionen. Dein Programm sagt also der Zugriffsschicht: Ich möchte ein "Objekt" in die Datenbank legen welches folgendem Template unterliegt.
Die Zugriffsschicht legt dann in der Datenbank z.B. zwei Feldobjekte vom Typ Varchar, ein vom Typ Int und eines vom Typ DateTime an und linkt diese an das konkrete "Objekt" welchem das entsprechende Template zu grunde liegt.

Damit brauchst du dann allerdings keine ObjektDB weil du sowieso wieder alles in die Einzelteile zerpflückst um möglichst generisch alle möglichen Typen abbilden zu können. Deshalb noch einen konstanten Teil dazu (die CDB) welche alle grundlegenden funktionen abdeckt. Die Objekte in der CDB haben dann ein Linkfeld was das anflanschen von den zusammengestöpselten Objekten erlaubt.

Dein Assembly welches das Datenmodell beinhaltet brauchst du dann eigentlich nie wieder zu ändern da du alles dynamisch zusammenbauen und anhängen kannst.
Die einzelnen Plugins die diese Erweiterungen benötigen können diese zusammengebastelten Objekte ja wieder wrappen womit dir innerhalb der Assemblies die diese Objekte typsicher zur verfügung stehen oder du benutzt eben property descriptoren und einen Factory-Ansatz.

Wenn ich dich richtig verstehe scheitert das ganze aber an der FastObjects Runtime:

Die FO-Datenbank kann ich nicht wie z.B. MS-SQL mit Managemen-Studio erstellen und bearbeiten. Ich erstelle ein Assembly und darin ist mein Klassenbaum. Die Klassen in die DB gehören werden als [Persistent] gekennzeichnet und ein FastObjects-Tool baut aus dem Assembly die DB und erweitert danach mein Assembly um interne DB-Funktionen...

Also muss im Assembly der Klassen-Baum fix aufgebaut sein. Ich kann nicht direkt auf die DB zugreifen und sagen hallo Klasse gib mir Felder, eine Objekt-Definition bauen und dann Daten aus der DB laden und daraus ein Objekt erstellen mit dem ich arbeiten kann - Das macht die FO-Runtime.
FastObject ist eben leider in der C# Runtime nicht so aufgebaut, dass die Dynamik die ich haben will so möglich ist.
Also Brauch ich für jede Kunden-DB ein Assembly mit dem Baum...

lg

Ich habe zwar noch nicht ganz kapiert für was wir das wirklich verwenden, aber wir haben PostSharp laufen.
Laut den Erzählungen von meinen Kollegen geht dieses Programm her, öffnet die Assembly schreibt bei einer Property noch einen funktionsaufruf hin und kompiliert die Assembly neu.
damit könntest Du ja auch dein "Script" dazu rein packen.
Such mal danach im google, gibts sicher was.

Hallo spike24 und danke für deinen Beitrag!

Ich diskutiere genau diese Funktion grade im PostSharp Forum....
Wenn da was rauskommt poste ich natürlich...

thx

[EDIT]

It does not place any restrictions on your object model, and fully supports the concepts of inheritance, interfaces and .NET Framework collections.

Hört sich für mich so an als ob man so ziemlich alles was man in memory abbilden kann auch persistieren kann.

[EDIT2]

Ich kann nicht direkt auf die DB zugreifen und sagen hallo Klasse gib mir Felder

OQL?

Also jetzt mal total simpel in etwa so (wenn ich Zeit finden sollte kann ich es ja mal anhand eines Beispielprojekts (ohne Datenbank) zeigen):

Das hab ich schon verstanden aber wie gesagt - Das Problem daran ist die FO-Runtime
Ich brauche ein Assembly mit dem Baum (Klassen und keine Interfaces).
Dieses Assembly wird von FastObjects fix mit der DB verbunden.
Also muss ich mein Assembly erstellen, daraus die DB und dann kann ich die DB laden.
Ändere ich nach dem Erstellen der DB das Assembly muss die DB wieder aus dem Assembly upgedatet und neu verlinkt werden.
Das geht nur mit einem FO-Tool und das kann ich nicht beeinflussen...

Denke dass Soucre (verschlüsselt) ausliefern, Erweiterungssource des Kunden hinzufügen, Assembly kompilieren und dann DB updaten der beste Weg ist.
Bzw. der ein einzig mögliche...

Nur wie gesagt dazu wäre CodeCompileUnit aus Source oder Assembly eine Hilfreiche Funktion - Diskutiere das gerade mit PostSharp...
Wenn das funktioniert wie ich mir das wünsche könnte ich sogar darauf verzichten den Original-Source auszuliefern...

thx

Hört sich für mich so an als ob man so ziemlich alles was man in memory abbilden kann auch persistieren kann.

Nicht immer alles glauben, was das Marketing verspricht...

OQL?

Das Resulat eines OQL-Querys ist eine IList<T>
Wenn es T in meinem Programm nicht genau so gibt wie in der DB ist das Resultat eine Exception...

😉 Ich habe diese DB nicht gekauft.

An der DB selber ist sonst nichts auszusetzen.
Das Problem ist, dass FastObjects so konzipiert ist, dass Version von Applikation und DB immer zusammenhängen.
Das nächste Problem ist, dass es weltweit nur eine Softwarefirma gibt die ebenfalls mit einer Kundenspezifischen DB arbeitet und die schreiben C++…
Darum ist der Support von FastObjects in diesem Punkt leider recht eingeschränkt…

Wenn es T in meinem Programm nicht genau so gibt wie in der DB ist das Resultat eine Exception...

Wenn interfaces nicht wie erwartet funktionieren was ist dann mit vererbung?

Sorry, aber ich verstehe die Frage nicht.

Ich kann den Klassenbaun nicht rein aus Interfaces bauen.

Irgendwie frage ich mich hier und in der anderen Diskusion, warum
es denn mit fastobject gemacht werden soll.

Könnte es sein, das hier jemand den Sinn und Zweck von OODB's und Co nicht wirklich verstanden hat?

Eine OODB ist genauso wie z.b. ein ORMapper oder das Typsierte DataSet
dazu da, einen typisierten und deshalb aber eingeschränkten Zugriff auf
Daten zu haben.

Wenn Du es Dynamisch haben willst, brauchst du eigentlich überhaupt keine
externen sachen einkaufen, da das DataSet und damit auch ADO.NET dies
von Haus aus bietet.

Ich kann auch versuchen mit nem Ferrari die ganzen Einzelteile meines
Neubaus zu transportieren, und mit Anhängerkupplung und Co wird das
auch klappen, aber der Transporter ist da echt besser für geeignet,
und deutlich günstiger.
Und sparen tut man auch nix durch den Ferrari.
Und cool sieht das auch nicht aus.

Jetzt hattest du mich schon so weit das ich die FastObjects Trial heruntergeladen habe aber als ich den Server dann starten wollte sagte der mir das ich ihn leider nicht auf dual core CPUs ausführen kann weil ich dann eine Multiprozessor-Lizenz bräuchte...

Wenn ich mir noch eine Frage erlauben dürfte: Was war der Bewegrund von der Relationalen Datenbank weg zu gehen?

Ich kann den Klassenbaun nicht rein aus Interfaces bauen.

Aber doch wohl aus stinknormalen Basisklassen?

@FZelle

Hallo und doch doch! Haben wir schon verstanden 🙂

Es gab diverse Gründe (hauptsächlich rechtliche) die gegen Andere DB's sprechen.
Es war ein langer Weg und die Entscheidung FastObjects steht fest.
Möchte hier aber unsere internen Überlegungen nicht unbedingt breittreten...

lg

Aber doch wohl aus stinknormalen Basisklassen?

Ja, das schon, verstehe deine Frage

Wenn interfaces nicht wie erwartet funktionieren was ist dann mit vererbung?

trotzdem nicht... Bzw. Was du damit fragen willst...

Naja wenn der Ansatz den ich beschrieben habe nicht mit Interfaces zu realisieren ist so sollte er doch wenigstens mit einer Basisklasse funktionieren.

Es kann ja sein, dass ich dich falsch verstehe, aber ich kann die Typen nicht erst zu Laufzeit erstellen.

Ich brauch eine fixes Assembly mit dem Baum und das darf ich nach DB-Update nicht mehr verändern...

Das ist ja fix und zur compile-zeit bekannt. Aus dem vohergehenden Text hat sich das für mich so angehört als wäre das euer altes Konzept gewesen.

Du baust ja nicht direkt objekte, deshalb habe ich das Wort auch immer in Anführungsstriche gesetzt, sondern du baust dir eine generische Datenbankstruktur die einzig und allein für Anpassungen verwendet wird.

Ich brauch eine fixes Assembly mit dem Baum und das darf ich nach DB-Update nicht mehr verändern...

Das berücksichtigt der Ansatz, das einzige Manko könnte die Performance sein und das die Benutzung (Für den Entwickler) nicht mehr wirklich intuitiv ist.

Schau dir das Beispiel von oben noch mal an... Du hast Objekte die einfach nur Felder repräsentieren und Objekte die diese in einer Liste beinhalten.

Zur Laufzeit baust du deine "Objekte" einfach nur zusammen in dem du dich ausschließlich der bestehenden Struktur bedienst.

Das hätte ich evtl. schon früher anbringen können aber ich kam selber nicht drauf: Eigentlich ist es das Composite Pattern.

Ich denke der beste Weg ist dennoch die Lösung Source mit ausliefern und Assembly dann beim Kunden kompilieren.
Ich spar mir einige Probleme, mache das Ganze nicht unnötig kompliziert und muss auch nicht an Performanceprobleme etc. denken

Danke für die Hilfe!

Na denn wünsch ich mal viel Erfolg.

Hallo webbi,

wenn du darauf bestehst das Assembly zu modifizieren (was mir sehr Suspekt ist) kannst du dir mal Mono.Cecil und das Tutorial dazu ansehen welches ich vor einiger Zeit hier gepostet habe.

Gruss
tscherno

Danke tscherno!

Sieht gut aus!

Wenn ich jetzt noch eine Möglichkeit finde aus Source eine CodeCompilerUnit zu erstellen wär ich (vorerst) wunschlos glücklich 🙂

thx

So, also das mit dem Code ausliefern und daraus kundenspezifisch Assembly und DB funktioniert perfekt.

Warum ich das vorher nicht gefunden habe verstehe ich auch nicht, aber CSharpCodeProvider.Parse erstellt eine CodeCompileUnit aus Source - jedenfalls laut Beschreibung - Ich hab's noch nicht versucht...

lg

Hi webbi!

Eigentlich hat FZelle alles gesagt, was du in einem C# Forum erwarten kannst. Wir arbeiten ja schließlich mit einer objektorientierten Programmiersprache. Wenn die Anforderung an die Anwendung ist, daß die Kunden zusätzliche Felder und/oder Methoden definieren können, dann muß das eben im Objektmodell so abgebildet werden. Das ganze hat nichts damit zu tun, daß ihr eine objektorientierte Datenbank habt. In einer relationalen Datenbank hat man bspw. die Möglichkeit, dynamisch neue Tabellen zu erstellen, wenn neue Objekte eingeführt werden, aber das ist auch keine saubere Lösung. Daß Fastobjects alle Objekte nimmt und irgendwie speichert, heißt noch lange nicht, daß man jetzt auch den Code der Anwendung dynamisch erzeugen muß.

Mit anderen Worten ausgedrückt: Würdet ihr die Zeit, die ihr mit der Frage "Wie schreibe ich mir eine Anwendung, die mir eine Anwendung schreibt" verbringt dazu nutzen, über ein vernünftiges Klassen- und Datenbankdesign nachzudenken, hättet ihr am Ende mehr davon.

Daß es vorher auch funktioniert hat, ist kein Argument, im Gegenteil wäre der Umstieg von Delphi auf .NET ein guter Grund über eine saubere, objektorientierte Lösung nachzudenken.

Wenn ihr es trotzdem schaffst, habt ihr meinen vollen Respekt, denn dann bräuchtet ihr zumindest keinen Obfuskator für euren Code mehr!

Schöne Grüße,
Christian

@MrSparkle:
Naja, eine OODB ist nun mal so aufgebaut, das sie definierte Objekte speichert.

@Webbi:
Ich persönlich mache schon seit Jahrzehnten mit Datenbanken rum,
und es ist witzig, das die Entscheidung für Fastobjects "nur" wegen
lizenzen enstanden ist, wo es doch wirklich performante und echt kostenlose
RDBMS gibt.

Aber das ist ja jetzt euer problem.

...es ist witzig, das die Entscheidung für Fastobjects "nur" wegen
lizenzen enstanden ist...

Da hast du wohl was falsch verstanden...

Du schriebst oben "(hauptsächlich rechtliche)" Gründe, das sind für mich in
99% der Fälle Lizenzrechtliche Sachen.

Aber wie gesagt, fahr du mir dem Ferrari ruhig zum Baumarkt 😉

ok, hat mit den Lizenzen nix zu tun... - FO ist ja alles andere als Kostenlos...

Und mitterweile fährt mein FO-Ferrari schon so wie er soll 🙂

*hehe* Ein Ferrari mit Anhängerkupplung 👍

Frauen stehen ja bekanntlich auf praktische Autos 🙂 ?

Bitte beim Thema bleiben !!!

Nun zu deinem Problem:

Wenn ich deine Problematik anschaue, dann denke ich gleich an Access, Navision, usw. Diese Anwendungen sind auch Anwendungen mit der man die Anwendung selber erweitern kann. Wieso baust du dein Datenbankschema nicht so auf das du den Quellcode nicht "mitschicken" musst?

Hallo burnig snow!

Weil meine aktuelle Lösung perfekt funktioniert und ich kein Problem darin sehe.

Es handelt sich nur um den Code des Klassenbaums und ein paar kleiner Funktionen. Außerdem wird der Code wird verschlüsselt ausgeliefert.

Da ich ansonsten das Original-Assembly im Nachhinein erweitern müsste kann ich es so oder so nicht den durch den Obfuscator jagen....

Und ob nun Decompilen oder Source entschlüsseln - Wer Freude dran hat, hat dann meinen Klassenbaum - Wünsche viel Freude dran... 🙂

Außerdem spare ich mir eine mögliche Probleme...

lg