[NodMot]

Ich weiß ja nicht, in welcher Branche Du tätig bist, wie groß Deine Firma ist, etc. und kann deshalb nicht sagen, wie einfach Deine Organisation zu halten ist, oder nicht.

Aber ich kann Dir mal ein paar Beispiele von uns nennen. Z.B gab es zwei Kern-DLLs, die in allen Systemen gleich gehalten werden konnten.
Urplötzlich (vom einen auf den anderen Tag) wurde vom Vorstand des Mutterkonzerns bekanntgegeben, daß ein Unternehmen im europäischen Ausland aufgekauft wird, die Verhandlungen mehr oder minder abgeschlossen sind und bestimmte Systeme "direkt" nach Belgien übernommen werden sollen, um eine einheitliche Logistikstruktur zu bekommen. Dazu gehört nicht nur eine 1:1-Portierung, sondern eine Übersetzung ins englische, flämische und wallonische (OK, das hat nicht viel mit dem eigentlichen Problem zu tun, sondern soll nur mal verdeutlichen, was plötzlich organisatorisch umgeworfen werden kann) und es müssen aber auch Dinge geändert werden, weil nunmal bestimmte Sachen nach belgischem Recht ganz anders laufen.
Und da gehst Du weder zum Vorstandschef vom eigenen Konzern mit 30000 MA, noch zum Chef des Mutterkonzerns mit etwa 55000 MA und erzählst ihm etwas von Versionsproblemen von DLLs aufgrund dessen die geplante Firmenübernahme mit den angedachten Prozeßen erstmal etwas warten soll, um auch alle Syteme anpassen zu können. Sorry, aber der lacht mich aus und sagt, daß ihn solche Kleinigkeiten nicht interessieren, sondern nur, daß er seinen Jahresumsatz von 45 Milliarden Euro wie geplant um 10 % steigern will.
Ein weiteres "einigermaßen" aktuelles Beispiel war die Änderung des Rabattgesetzes in Deutschland, die sich zwar schon etwas längerfristig ankündigte, aber dennoch Planungen umwarf. Das ist etwas anderes, als vielleicht einen reinen Softwarebetrieb zu führen, in dem man abgeschlossene Produkte nach draußen verkauft.


Nun aber zu meiner eigentlichen Antwort, die ich noch geben wollte:

Ich gebe zu, daß COM die DLL-Hölle nicht allein verursacht hat. Ich gehe auch darin mit überein, daß wenn man in einer abgeschotteten Welt lebt, in der nur man ganz allein DLLs kompiliert, es für den Entwickler kein Problem darstellt, eine komplett neue Version seiner DLL zu registrieren.
Was aber, wenn andere auch auf die DLL zugreifen können sollen und zwar auf die aktuelle Version und ohne Entwicklungsaufwand (also ohne die neuen GUIDs verwenden zu müssen)? Und wenn noch dazu gefordert ist, daß auf zentral im System registrierte DLLs zugegriffen werden soll (es gibt ja gute Gründe für sowas) und eben kein Wildwuchs mit vielen Versionen in verschiedensten Anwendungsverzeichnissen getrieben werden soll ?
Wenn im Unternehmen nur mit VB programmiert werden soll (wo mir beim besten Willen kein trivialer Weg einfällt, eine DLL ohne GUID zu laden) ?
Wer meint, er könne seine Schnittstellen immer so universell planen, daß ihre Rückwärtskompatibilität niemals gebrochen werden müßte, der ist entweder ein Hellseher oder extrem naiv (bitte nicht persönlich nehmen, ich nehme einfach an, wir arbeiten nicht in den gleichen Welten). Und da kommt die (Er-)Lösung eben erst mit dem GAC-Konzept des .Net-Frameworks, das die Vorteile einer zentralen Registrierung von Komponenten mit der Möglichkeit einer Versionierung verbindet, was auch den Konfigurationsaufwand beträchtlich reduziert.
Wenn man die Perspektive nun noch etwas erweitert und bedenkt, daß moderne Unternehmenssoftware auch oft auf Komponenten von Drittanbietern angewiesen sein kann, kommt man eigentlich erst richtig ins Schwitzen, denn diese sind quasi immer zentral registriert und unterscheiden sich eben oft auch zwischen Versionen mit gleicher Schnittstelle in ihrem Verhalten. Warum sonst sollte der Drittanbieter die "Zwischenversion" herausgebracht haben? In einer idealen Welt würde man nun immer dafür sorgen, daß auf allen Maschinen, auf denen Software zu installieren ist, immer der genau gleiche Stand an Komponentenversionen herrscht. Genau darauf zielen natürlich auch unsere Konfigurationskonzepte ab.
Nun leben wir allerdings nicht in einer idealen Welt und so ist schon die relativ überschaubare Landschaft wie die unseres Unternehmens mit nur einigen hundert relevanten Servern (und einigen Tausend Citrix-Clients) auch bei den größten Anstrengungen nur sehr bedingt immer auf dem gleichen Stand zu halten. Der Standardfehler, der immer wieder auftritt, ist zum Beispiel der, daß die Datenzugriffskomponenten auf der Entwicklermaschine und der Produktionsmaschine sich in kleinen Details unterscheiden, was dann oft auch zu Programmabstürzen führt, die auf der Entwicklermaschine nicht passiert sind. Eine zentrale Registrierung mit Versionierung löst dieses Problem äußerst elegant, indem eben einfach immer alle theoretisch benötigten Versionen zentral abrufbar sind. Man kann sich als Entwickler darauf verlassen, daß die richtige Version da ist. Und wenn eine sehr neue Version dann eben doch noch nicht auf allen Produktionsmaschinen installiert ist, kann man sie sofort, ohne Entwicklungsaufwand und ohne Auswirkungen auf andere installierte Software einfach dazu installieren. Das geht mit COM nun beim besten Willen nicht, sondern höchstens ansatzweise mit dem Workaround mit der anwendung.exe.local - Datei, was aber erhöhten Konfigurationsaufwand nach sich zieht.

Um mal auf die Eingangsfrage zurückzukommen:
Die DLL-Hölle mag schon vor COM bestanden haben, ich kann allerdings nicht erkennen, inwiefern COM und die IDL dazu beigetragen haben sollten, sie zu lindern. Eher das Gegenteil ist der Fall.

Nun noch ein paar spezielle Aspekte:

Original geschrieben von ComSubVie
Mal abgesehen davon, das du die DLL nicht unbedingt mit deren GUID laden musst (wie das mit den windoof CreateInstance & Co Funktionen geht).

Das würde mich ja mal interessieren. Ich möchte mich hier nicht als COM-Experten aufschwingen, aber mit CoCreateInstance oder einer ClassFactory kann man meines Wissens keine Klasse aus einer DLL laden ohne CLSID (was ja auch eine GUID ist). Wenn Du einen anderen Weg meintest, würde mich dieser wirklich sehr interessieren!

Original geschrieben von ComSubVie
Außerdem kannst du die DLL auch registrieren bevor du die verwendest, und nachher wieder die ursprüngliche. Das funktioniert zwar nicht so einfach, aber es geht.

Das kann es ja wohl nicht sein. Denn was passiert bei einer solchen Lösung, wenn zur Laufzeit ein anderes Programm die ursprünglich registrierte DLL benötigt? Das ist riskantes Gefrickel.

Original geschrieben von ComSubVie
Also ich kann IDL auch für CORBA, C++ @Linux und Java verwenden.

C++ hatte ich ja bereits aufgeführt und dies sollte nun wirklich keine absolute Vollständigkeit beanspruchen, denn dafür kenne ich nunmal einfach nicht alle Programmiersprachen dieser Welt.