C# und C++ DLLs

[Nico Graichen]

Hi

Darf ich fragen, warum du das machst?
In den Interops stehen nur Verweise auf MEthoden, welche vom COM Server zur Verfügung gestellt werden. Also keine Implementierung etc.
Die Verweise in eine DLL zu packen halt ich für weniger gut. Die einzelnen Interops werden so gelinkt, wie sie benötigt werden. Packst du alles in eine, linkst du jede Menge ohne das du es brauchst. Brauch dein Programm z.B. die Methoden einer COM DLL gar nicht, muss auch die Interop nicht gelinkt werden. du machst das so aber doch und machst dein Programm dadurch nur langsamer.

 

[Passer]

Im Endeffekt stehen in den Interop Assemblies ja überwiegend nur die Schnittstellen zu den COM-DLLs.

Ob das nun in den Interop Assemblies drin steht, oder im Programm sollte meines Wissens egal sein, da nur dann instantiert werden sollte, wenn eine "Instanz" der Schnittstelle erzeugt wird.

Und in meinem Falle brauche ich alle Interop Assemblies, die ich benutze. Sonst würde ich sie ja nicht benutzen.

 

[Nico Graichen]

Im Endeffekt stehen in den Interop Assemblies ja überwiegend nur die Schnittstellen zu den COM-DLLs.

Um genauzu sein, Verweise auf Methoden, welche vom COM-Server für diese Komponente zur Verfügung gestellt werden können
Kurz gesagt der Inhalt der IDL

Ob das nun in den Interop Assemblies drin steht, oder im Programm sollte meines Wissens egal sein, da nur dann instantiert werden sollte, wenn eine "Instanz" der Schnittstelle erzeugt wird.

Wieso willst du dein Programm unnötig mit den Deklarationen aufblähen? Da das Code ist, den du sowieso nicht änderst, kann der doch auch in den Interops bleiben

Und in meinem Falle brauche ich alle Interop Assemblies, die ich benutze. Sonst würde ich sie ja nicht benutzen.

Das ist mir schon klar. Aber DLL heißen so, weil sie nur dann gelinkt werden, wenn sie auch gebraucht werden. Muss deine Anwendung nicht auf ein COM-Interface zugreifen, muss die dazugehörige DLL auch nicht gelinkt werden. So wie du das vorhast, linkst du statisch und belegst nur unnütz Speicher.

 

[Passer]

Wie ich schon sagte. Ich habe nur vor, meinen Quellcode mit Interops von DLLs aufzublähen, die ich ohnehin benutze.

Da habe ich dann lieber eine grössere Exe, als zig DLLs, deren Stand mit der eigentlichen exe zusätzlich bei Updates als Fehlerquelle beim Kunden dienen können.

Da habe ich lieber alles in einer .exe (oder meinetwegen auch in einer Assembly), anstatt jedes mal darauf acht zu geben, dass auch ja alle benutzten Assemblies mit der exe mitgeliefert und kopiert werden (ja, ich weiss, dass alle dazu müssen, der Kunde vielleicht auch, aber es reicht ja schon, wenn in dieser Kette noch 1-2 Glieder zwischen sitzen, die vielleicht meinen, es besser zu wissen, schon kommt es zu Problemen, weil irgendwas nicht kopiert wurde. Jeder behauptet dann, dass er alles wie gesagt gemacht hatte, ich such mich nach dem Fehler dumm und dusselig, nur weil es einer verbaselt hat, alles so zu machen, wie es ihm aufgetragen wurde. Obiges Szenario hatte ich schon zu oft, um e ssich nicht wegzuwünschen; da hilft kein man könnte, hätte, würde... Der Ansatz, alles möglichst kompakt zu verpacken istd er einzige Ansatz und ich denke, dass man im Jahre 2006 nicht mehr unbedingt auf das bisschen Speicher zu achten hat, wenn sich dadurch dermassen viel Zeit und auch damit verbundene Kosten einsparen lassen (für die Zeit, die ich schon für obige Szenarien verschwendet habe, wären locker n paar GB Ram drin gewesen)).

MfG
Passer
PS.
Um es noch einmal zu wiederholen.
Natürlich benutze ich alle Interop DLLs, die ich vorhabe in den Code zu packen auch. Sonst wäre es ja Blödsinn.

 

[Nico Graichen]

Wie ich schon sagte. Ich habe nur vor, meinen Quellcode mit Interops von DLLs aufzublähen, die ich ohnehin benutze.

du weißt, was dynamisches Linken ist, oder? Und wo die Vorteile liegen?

Da habe ich dann lieber eine grössere Exe, als zig DLLs, deren Stand mit der eigentlichen exe zusätzlich bei Updates als Fehlerquelle beim Kunden dienen können.

Da habe ich lieber alles in einer .exe (oder meinetwegen auch in einer Assembly), anstatt jedes mal darauf acht zu geben, dass auch ja alle benutzten Assemblies mit der exe mitgeliefert und kopiert werden (ja, ich weiss, dass alle dazu müssen, der Kunde vielleicht auch, aber es reicht ja schon, wenn in dieser Kette noch 1-2 Glieder zwischen sitzen, die vielleicht meinen, es besser zu wissen, schon kommt es zu Problemen, weil irgendwas nicht kopiert wurde. Jeder behauptet dann, dass er alles wie gesagt gemacht hatte, ich such mich nach dem Fehler dumm und dusselig, nur weil es einer verbaselt hat, alles so zu machen, wie es ihm aufgetragen wurde. Obiges Szenario hatte ich schon zu oft, um e ssich nicht wegzuwünschen; da hilft kein man könnte, hätte, würde... Der Ansatz, alles möglichst kompakt zu verpacken istd er einzige Ansatz

Doch es gibt wenn und aber:
Eine ordentliche Versionierung und feste Schnittstellen verursachen auch keine Inkompatibilitäten

und ich denke, dass man im Jahre 2006 nicht mehr unbedingt auf das bisschen Speicher zu achten hat, wenn sich dadurch dermassen viel Zeit und auch damit verbundene Kosten einsparen lassen (für die Zeit, die ich schon für obige Szenarien verschwendet habe, wären locker n paar GB Ram drin gewesen)).

da fallen mit nur 2 Worte ein: schlechte Einstellung

Um es noch einmal zu wiederholen.
Natürlich benutze ich alle Interop DLLs, die ich vorhabe in den Code zu packen auch. Sonst wäre es ja Blödsinn.

siehe oben.
Es geht nicht um die Referenzen, die du deinem Projekt hinzugefügt hast sondern um den Zeitpunkt wann DLLs gelinkt werden.
Und du linkst statisch!

 

[Passer]

du weißt, was dynamisches Linken ist, oder? Und wo die Vorteile liegen?

Ja, ich denke schon, Allerdings geht es mir nur sehr wenig darum, denn ich benutze alle Interop DLLs, die ich vor habe in code zu übersetzen. Da in diesem Fall quasi kein Dynamisches Linken vorliegt, ist das Vorhaben imho durchaus sinnvoll (es handelt sich übrigens um selbst erstellte C Bibliotheken, welche es nach C# zu portieren ein wenig zu aufwendig wäre

Doch es gibt wenn und aber:
Eine ordentliche Versionierung und feste Schnittstellen verursachen auch keine Inkompatibilitäten

Schon klar, dann versuche das mal einem Kunden zu erklären, der noch den ein oder anderen Featurewunsch hat.

da fallen mit nur 2 Worte ein: schlechte Einstellung

Und mir fällt dazu ein:
Zuviel Freizeit
siehe oben.
Es geht nicht um die Referenzen, die du deinem Projekt hinzugefügt hast sondern um den Zeitpunkt wann DLLs gelinkt werden.

Und du linkst statisch!

Du hast angefangen zu nehaupten, ich würde dynamisch linken.

Deshalb habe ich auch Deine Einwände nicht verstanden.
Ich wollte bloss wissen, wie ich das Interop DLL Chaos (viele Datein, viele Fehlerquellen beim Anwender) mit möglichst wenig Aufwand (= Zeitersparnis) in den Griff bekomme.
Und da nicht jeder Anwender fortgeschrittene IT Kenntnisse hat, hat es sich als recht effizient herausgestellt, mögliche Fehlerquellen und Updates tz vermeiden und das bspw. Anwendungsverzeichnis möglichst schmal zu halten. (wenig Assemblies und Komponenten und allenfalls 1-2 Konfigurationsdateien).

Hier aufzulisten, was mir schon an gemachten Fehlern untergekommen ist, würde Seiten füllen. Deshalb stehen derzeit alle anderen Möglichkeiten ausser Frage (sonst hätte ich diese gestellt).

MfG
Passer

 

[Nico Graichen]

Und mir fällt dazu ein:
Zuviel Freizeit

Das hat nichts mit Freizeit zu tun sondern mit ordentlicher und resourcenschonender Programmierung

Du hast angefangen zu nehaupten, ich würde dynamisch linken.

Du nutzt COM und COM-DLLs werden für gewöhnlich dynamisch gelinkt.

Deshalb habe ich auch Deine Einwände nicht verstanden.
Ich wollte bloss wissen, wie ich das Interop DLL Chaos (viele Datein, viele Fehlerquellen beim Anwender) mit möglichst wenig Aufwand (= Zeitersparnis) in den Griff bekomme.
Und da nicht jeder Anwender fortgeschrittene IT Kenntnisse hat, hat es sich als recht effizient herausgestellt, mögliche Fehlerquellen und Updates tz vermeiden und das bspw. Anwendungsverzeichnis möglichst schmal zu halten. (wenig Assemblies und Komponenten und allenfalls 1-2 Konfigurationsdateien).

Wofür braucht man fortgeschrittene IT-Kenntnisse, um z.B. eine Setup.exe auszuführen

 

[Christian Kusmanow]

schon kommt es zu Problemen, weil irgendwas nicht kopiert wurde. Jeder behauptet dann, dass er alles wie gesagt gemacht hatte, ich such mich nach dem Fehler dumm und dusselig, nur weil es einer verbaselt hat, alles so zu machen, wie es ihm aufgetragen wurde. Obiges Szenario hatte ich schon zu oft, um es sich nicht wegzuwünschen; da hilft kein man könnte, hätte, würde...

Blödsinn, wenn Du in deiner Main Methode bereits auf NameSpaces deiner Solution zugreifst,
ist das vorprogrammiert. Dein Programm hat dann keine Chance mehr,
darauf zu reagieren und und der User bekommt eine Laufzeitfehlermeldung,
was nicht wirklich besonders professionell wirkt...

Wenn Du aber hingegen in der MainMethode eine weitere Klasse instanzierst, in der erst auf
Namespaces (Assemblys) deiner Solution zugegriffen wird, hast die Möglichkeit das ganze anzufangen.
Dann kann dein Program dem User sagen was für eine Assembly fehlt und was er machen muss,
damit dieses Problem behoben wird. (neu installieren)

Das hat nichts mit Freizeit zu tun sondern mit ordentlicher und resourcenschonender Programmierung

Nicht nur das. Die Wartbarkeit einer Anwendung minimiert sich, jeh größer die Assemblys
und Abhängigkeiten der einzelnen Namespaces zueinander werden.
Wurschtelst Du mehere völlig unterschiedliche Aufgabenbereiche (RootNameSpaces) in einer Assembly zusammen
können sich Nachlässigkeiten in Bezug auf auf Unabhängigkeit der einzelnen Komponenten untereinander einschleichen.
Das bedeutet das Du kaum Änderungen vornehmen kannst,
ohne das diese geringfügigen Änderungen Probleme nach sich ziehen.
Weiterhin ist das Extrahieren von vorhandenen Implementierungen nur mit viel Aufwand verbunden.

Letztendlich glaube ich nicht das Du bereits so viel released hast,
dass Du dir so sicher sein könntest dass sich dein beschiebenes Scenario nicht weg wünschen ließe.