Dynamische Dll vs. Assemblies und .NET

[Andreas Kosch]

Hallo,

auch in der .NET-Welt kann die Anwendung den Code für Assemblies generieren und in Form einer Assembly-DLL auf die Platte schreiben. Eine einmal in den Arbeitsspeicher geladene Assembly kann jedoch nur dann (indirekt) entladen werden, wenn die <i>Application Domain</i> (AppDomain) entladen wird (im Gegensatz zum Win32-Prozess kann ein .NET-Prozess aus verschiedenen als AppDomains voneinander angeschotteten Speicherbereichen bestehen).

Generell muss sich jede Assembly, die als managed code ausgeführt werden soll, in die Karten blicken lassen (IL). Allerdings existiert da im .NET Framework der <i>CLR Native Image Generator</i> (ngen.exe), der eine Assembly fertig compiliert auf der Platte ablegt. Die CLR führt dieses vorkompilierte Gebilde jedoch nur dann sofort aus, wenn sich die Umgegungsbedingungen nicht geändert haben

[aagoch]

Dynamische Dll vs. Assemblies und .NET

Hallo,

Unsere Win32-API Anwendung ist wie ein 'RunTime Framework' aufgebaut. Das bedeutet, die Benutzer die nur elementare Programmierkenntnisse besitzen, können einfache Pascal/ObjectPascal- bzw. C/C++ - Methoden definieren. Das Programm vervollständigt die Quellcode und kompiliert sie zu einer Dll, die dann dynamisch geladen wird. Ein Teil des Dll-Namens ist der Zeitstempel, so dass mehrere Version einer Funktionssammlung existieren.

Die Fragen:
In der eventuellen Zukunft ohne Win32-API soll das Programm die Benutzer-Code zu Assemblies vervollständigen?

Wird die Anwendung in der Lage sein die erstellten Assemblies mit verschiedenen Zeitstempeln gleich zu laden, zu entladen oder gar zu löschen?

In dieser obengenannten Zukunft wird es möglich sein, das Programm in einer binären Form zu verteilen oder kommt nur IL-Form in Frage?

Vielen Dank.

[aagoch]

Danke Herr Kosch für die rasche Antwort,

momentan lädt die Anwendung 100-te von diesen benutzerdefinierten DLL's ein und aus. Bedeutet es, dass alle diese Assemblies so lange im Speicher bleiben müssen, bis das Programm geschlossen wird?

Zu meiner letzten Frage: können die Anwendungen selbst erst nach binärer Kompilierung an die Benutzer verteilt werden (nicht in IL) oder es ist noch nicht endgültig klar was Microsoft mit dem Framework vorhat?

Dank

[Andreas Kosch]

Hallo,

&gt;..bis das Programm geschlossen wird?

Nein, wenn alle diese Assembly-DLL in eine vom Hauptprogramm abgetrennte Application Domain geladen werden, können die DLLs zur Laufzeit aus dem Speicher geworfen werden.

&gt;..selbst erst nach binärer Kompilierung .

Was ist mit "binärer" Kompilierung gemeint? Im Formalfall wird eine .NET-Assembly erst zur Laufzeit durch den JIT-Compilier in native CPU-Instruktionen übersetzt. Die Alternative NGEN.EXE erledigt den Job des JIT-Compilers bereits (wenn auch in nicht so effektiver Form) zum Zeitpunkt des NGEN.EXE-Aufrufs. Allerdings führt die CLR das NGEN.EXE-Ergebnis (fertiges Kompilat) nur dann direkt aus, wenn dies nicht mit den aktuellen Regeln auf diesem Rechner kollidiert

[aagoch]

Danke und Sorry, war im Urlaub.

>...binäre Kompilierung:
meine ich das im .NET Framework erstelltes Hauptprogramm selbst - sie wird doch normalerweise auch erst mit JIT-Compiler übersetzt? Kann man dieses nach erstem Start kompiliertes Programm weitergeben?

Wenn Nein, gibt es bereits die Möglichkeiten den in MSIL übersetzten Text zu verschlüsseln ohne große Performance-Verluste?

Vielen Dank