Abwärtskompatibilität von DLL- und COM-Schnittstellen — Eine Entscheidungstabelle dafür, welche Änderungen Aufrufer brechen

„Können wir für diesen Fix einfach die neue DLL austauschen, oder brauchen die Aufrufer auch einen Neubau?“ — wer eine gemeinsam genutzte DLL oder COM-Komponente pflegt, auf die mehrere Anwendungen verweisen, landet bei jedem Release bei genau dieser Frage. Beantworten Sie sie falsch, kann eine beim Kunden noch laufende alte EXE komplett den Start verweigern — oder schlimmer, sie startet weiterhin klaglos, während sich ihre Berechnungsergebnisse still und leise darunter ändern.

Was das Ganze knifflig macht: Die Entscheidung wird meist aus einem vagen „das fühlt sich riskant an“-Bauchgefühl heraus getroffen. In Wirklichkeit lässt sich fast mechanisch bestimmen, welche Änderungen die Kompatibilität brechen. Native DLLs haben klar definierte Regeln rund um Exporte und Aufrufkonventionen; COM hat die explizite, schriftlich niedergelegte eiserne Regel, dass Schnittstellen unveränderlich sind¹; und .NET verfügt über eine veröffentlichte Liste von Kompatibilitätsänderungsregeln, die Microsoft selbst bei der Entwicklung der .NET-Bibliotheken verwendet².

Auf diesem Blog haben wir die Grundlagen von COM bereits in Was ist COM / ActiveX / OCX? und dessen Designphilosophie in Was ist COM — Warum das Design von Windows-COM auch heute noch trägt behandelt. Dieser Artikel ordnet als Entscheidungstabelle, welche Änderungen für DLLs, COM und .NET-Assemblies jeweils Aufrufer brechen, und behandelt das Verfahren, wenn ein Kompatibilitätsbruch unvermeidbar wird.

1. Das Ergebnis zuerst

• Kompatibilität hat drei Ebenen: binäre Kompatibilität (funktioniert ohne Neubau), Quellcode-Kompatibilität (funktioniert bei Neubau) und Verhaltenskompatibilität (das Verhalten ändert sich nicht). „Kein Neubau nötig“ ist nicht gleichbedeutend mit „sicher“ — Sie müssen auch die Verhaltenskompatibilität beurteilen.³
• Für native DLLs gilt als Grundregel: Einen Export hinzuzufügen ist sicher; einen bestehenden Export zu ändern oder zu entfernen ist ein Bruch. Funktionssignaturen, Aufrufkonventionen und Struct-Layout sind der binäre Vertrag selbst.
• Eine COM-Schnittstelle ist nach Veröffentlichung unveränderlich. Methoden nach der Veröffentlichung hinzuzufügen, zu entfernen oder umzuordnen verstößt gegen die Spezifikation; Änderungen müssen als neue Schnittstelle mit neuer IID hinzugefügt werden (IFoo → IFoo2).⁴¹
• VB6-/VBA-Clients nutzen frühe Bindung, die Vtable-Slot-Positionen fest einprogrammiert und sie damit zu den Aufrufern macht, die am ehesten durch jede Änderung am Layout einer Schnittstelle brechen.
• Für .NET wird veröffentlicht, was als Breaking Change an einer öffentlichen API gilt — Microsofts Kompatibilitätsänderungsregeln —, und die Liste klassifiziert nicht nur das Entfernen von Methoden oder Signaturänderungen, sondern auch das Hinzufügen von virtual zu einem Member und sogar das Umbenennen eines Parameters als Breaking Change.²
• Semantische Versionierung ist die Konvention, bei einem Breaking Change die Hauptversion zu erhöhen, funktioniert aber erst, wenn Sie eine Definition dessen festlegen, was als Breaking Change gilt.⁵ Sie können die Entscheidungstabelle dieses Artikels als diese Definition verwenden.
• Ist ein Kompatibilitätsbruch unvermeidbar, gehen Sie in dieser Reihenfolge vor: Alt und Neu parallel anbieten → eine Übergangsfrist → eine Bestandsaufnahme der Aufrufer → Abschaltung. Das Prinzip lautet, niemals alles auf einmal auszutauschen.

2. Die drei Ebenen der Kompatibilität — wer wann bricht

Was salopp als „Abwärtskompatibilität“ in einen Topf geworfen wird, gliedert sich tatsächlich in drei Ebenen. Selbst die offizielle Dokumentation von .NET klassifiziert Breaking Changes entlang der Linien Quellcode-, binärer und Verhaltenskompatibilität.³

Der wichtige Punkt zu diesen drei Ebenen ist, dass eine äußere Ebene brechen kann, selbst wenn eine innere Ebene intakt bleibt. Ein Fix, der beispielsweise die Bedeutung des Rückgabewerts einer bestehenden Funktion ändert, bewahrt sowohl die binäre als auch die Quellcode-Kompatibilität, während er nur die Verhaltenskompatibilität bricht. Weil diese Art von Änderung weder einen Linkfehler noch einen Kompilierfehler erzeugt, ist sie die Zeile in der Entscheidungstabelle, die am leichtesten übersehen wird.

Umgekehrt müssen Sie in einer Umgebung, in der jeder Aufrufer die Quelle besitzt und gleichzeitig neu gebaut werden kann (etwa ein internes System in einem einzigen Repository), nur Quellcode- und Verhaltenskompatibilität bewahren — binäre Kompatibilität kann aus den Anforderungen gestrichen werden. Ob irgendein Aufrufer Ihrer DLL ein Binary ist, das Sie nicht neu bauen können, ist die erste Weggabelung beim Lesen der Entscheidungstabelle.

3. Die Kompatibilitäts-Entscheidungstabelle für native DLLs (C/C++)

Die Kompatibilität einer nativen DLL wird durch ihre Export-Tabelle, Aufrufkonventionen und ihr Speicherlayout bestimmt. Wie eine DLL überhaupt gefunden und geladen wird, behandelt Wie die Namensauflösung von Windows-DLLs funktioniert; sobald das Laden gelingt, ist die folgende Tabelle der Maßstab zur Beurteilung der Kompatibilität.

Die Design-Leitlinie, zu der diese Tabelle führt, hat sich seit Jahrzehnten nicht geändert: Halten Sie die Grenze auf ein C-ABI beschränkt (extern "C"-Funktionen und einfache Structs) und erweitern Sie durch Hinzufügen von Funktionen. Dasselbe gilt, selbst wenn Sie eine native DLL aus C# bauen: Die in Wie man eine C#-Native-AOT-DLL von C/C++ aus aufruft behandelte Exportoberfläche wird genau nach dieser Tabelle verwaltet.

3.1 Die cbSize-Konvention — Win32s Trick, um Structs erweiterbar zu machen

Die klassische Gegenmaßnahme gegen „das Hinzufügen eines Struct-Members bricht Aufrufer“ ist die Win32-Konvention, ein Größenfeld an den Kopf des Structs zu setzen. Der Aufrufer füllt cbSize mit der ihm zur Kompilierzeit bekannten Struct-Größe und übergibt das; die DLL sieht sich diese Größe an, um zu bestimmen, welche Generation des Structs dieser konkrete Aufrufer versteht.

typedef struct KS_CONFIG {
    DWORD cbSize;      // Der Aufrufer setzt sizeof(KS_CONFIG)
    DWORD dwMode;
    DWORD dwTimeout;
    // Neue Member immer am Ende hinzufügen
} KS_CONFIG;

// DLL-Seite: cbSize nutzen, um Generationen zu unterscheiden, und für alte Aufrufer auf einen Standardwert zurückfallen
if (pConfig->cbSize >= FIELD_OFFSET(KS_CONFIG, dwTimeout) + sizeof(DWORD)) {
    timeout = pConfig->dwTimeout;   // Neuer Aufrufer
} else {
    timeout = DEFAULT_TIMEOUT;      // Alter Aufrufer
}

Tatsächlich wird das NOTIFYICONDATA-Struct der Windows-API genau nach diesem Schema generationsweise versioniert, und es ist offiziell dokumentiert, dass das Setzen des richtigen Werts in cbSize die Kompatibilität mit älteren Versionen von Shell32.dll erhält.⁶ Setzen Sie cbSize von Anfang an, also ab der allerersten Version, in die öffentlichen Structs Ihrer eigenen DLL, wandern spätere Erweiterungen von „Breaking Change“ auf die sichere Seite der Entscheidungstabelle. Allerdings müssen neue Member immer am Ende stehen, und das Ändern von Typ oder Reihenfolge eines bestehenden Members bleibt weiterhin verboten. Noch etwas: Bei einem für Ausgaben genutzten Struct übernimmt die DLL-Seite zusätzliche Verantwortung — Schreibvorgänge und Initialisierung müssen sich immer innerhalb der vom Aufrufer tatsächlich übergebenen cbSize bewegen. Bedingungslos die vollständige neue sizeof zu schreiben, läuft über den kleineren Puffer hinaus, den ein alter Aufrufer alloziert hat, und die DLL verursacht am Ende genau die Art von Bruch, die diese Konvention verhindern sollte.

4. Die eiserne Regel der COM-Schnittstellen — keine Änderungen nach Veröffentlichung

COM ist die Technologie, die auf dieses Problem die klarste Antwort gab. Gemäß der COM-Spezifikation folgt eine Schnittstelle diesen Regeln:

• Eine Schnittstelle hat eine eindeutige IID (Interface-ID).¹
• Eine Schnittstelle ist unveränderlich. Einmal erstellt und veröffentlicht, darf kein Teil ihrer Definition jemals geändert werden.¹
• Eine Methode hinzuzufügen oder zu entfernen oder ihre Semantik zu ändern bedeutet nicht, „eine neue Version der alten Schnittstelle“ zu erstellen — es bedeutet, eine neue Schnittstelle mit einer anderen IID zu erstellen.⁴

Der Grund für eine solche Strenge ist, dass die eigentliche Substanz einer COM-Schnittstelle ein binäres Layout ist — die Vtable, eine Tabelle von Funktionszeigern. Ein C++- oder VB6-Client programmiert zur Kompilierzeit fest ein, dass „Slot 3 GetName ist“ — eine Position. Fügen Sie nach der Veröffentlichung eine Methode ein, ruft der alte Client, völlig ohne Fehler, eine andere Methode auf. Genau deshalb hat COM die Operation des „Änderns“ einer Schnittstelle selbst aus der Spezifikation gestrichen und stattdessen folgendes Erweiterungsverfahren bereitgestellt.

// v1: bereits veröffentlicht. Nie wieder ändern
[object, uuid(1111....)]
interface ICalc : IUnknown {
    HRESULT Add([in] long a, [in] long b, [out, retval] long* result);
};

// v2: eine neue Schnittstelle mit neuer IID. Erweitert durch Vererbung von ICalc
[object, uuid(2222....)]
interface ICalc2 : ICalc {
    HRESULT AddChecked([in] long a, [in] long b, [out, retval] long* result);
};

Die implementierende Klasse (die Coclass) implementiert sowohl ICalc als auch ICalc2; alte Clients nutzen ICalc genau wie zuvor weiter, und neue Clients fragen ICalc2 per QueryInterface an. Die offizielle Versionierungstheorie für RPC/COM legt es genauso dar: eine neue Schnittstelle, die von der alten erbt, entspricht einer Nebenversionserhöhung, während das Ändern einer bestehenden Methode oder eines Typs eine vollständig neue, nicht erbende Schnittstelle erfordert — das Äquivalent einer Hauptversionserhöhung.⁷ Was dieses Schema funktionieren lässt, ist, dass QueryInterface einem Aufrufer erlaubt, zur Laufzeit sicher zu prüfen, welche Schnittstellen unterstützt werden. Die Eleganz des Designs hinter diesem Mechanismus haben wir in Was ist COM genauer betrachtet.

4.1 Verantwortungsteilung zwischen CLSID, ProgID und IID

Beim Nachdenken über COM-Versionierung hilft es, die Rollen dreier Arten von Bezeichnern zu trennen.⁸

• IID identifiziert eine Schnittstelle (einen Vertrag). Jede Änderung am Vertrag bedeutet immer eine neue IID.
• CLSID identifiziert die implementierende Klasse. Sie können die Implementierung bei gleichbleibender CLSID frei austauschen, solange Sie den Vertrag jeder veröffentlichten Schnittstelle einhalten.
• ProgID ist ein menschenlesbarer Alias (KomuraSoft.Calc.1), der zum Nachschlagen der zugehörigen CLSID in der Registrierung verwendet wird. Es ist üblich, sowohl eine versionierte ProgID als auch eine versionsunabhängige ProgID (KomuraSoft.Calc) zu führen, die immer auf die neueste Version zeigt, wobei letztere per CurVer auf die aktuelle Version abgebildet wird.⁸

Mit anderen Worten: „Die Implementierung aktualisieren“ gehört zur Welt von CLSID und ProgID, während „den Vertrag ändern“ zur Welt der IID gehört — vermengen Sie die beiden nicht. Möchten Sie die Registrierung ganz vermeiden, behandelt diese Option Was ist Reg-Free-COM?

4.2 Warum VB6-/VBA-Clients besonders zerbrechlich sind

Wenn VB6 oder VBA eine COM-Komponente über eine Projektreferenz nutzt (frühe Bindung), liest es die Typbibliothek zur Kompilierzeit, um Aufrufe aufzulösen. Frühe Bindung ist die empfohlene Form — Sie erhalten IntelliSense, Typprüfung und schnellere Ausführung⁹ —, doch der Preis ist, dass sie sich eng an das Layout der Typbibliothek bindet. Nicht nur eine Änderung an der Vtable einer Schnittstelle verursacht Ärger; sogar eine rein an den Definitionen der Typbibliothek vorgenommene Änderung kann als „die Referenz war beim Öffnen des Projekts defekt“ oder als Laufzeitfehler 430/438 auftauchen.

Das bedeutet, dass Komponenten mit VB6, VBA oder Excel-Makros als Aufrufer die Regel der Schnittstellen-Unveränderlichkeit am allerstrengsten durchsetzen müssen. Auch Typbibliotheken tragen eine Version (Major.Minor), die Sie bei jeder Vertragserweiterung erhöhen. Wie Sie beim Veröffentlichen typisierten .NET-Codes für VBA eine Typbibliothek generieren, behandelt Eine typisierte .NET-8-DLL von VBA aus aufrufen — dscom und TLB. Spät gebundene Clients, die nur CreateObject nutzen, lösen dagegen namentlich auf und sind damit widerstandsfähig gegen Layoutänderungen — sind aber ebenso einer Änderung an der Bedeutung einer Methode (Verhaltenskompatibilität) ausgesetzt.

5. .NET-Assembly-Kompatibilität — mechanisch mit den offiziellen Regeln beurteilen

.NET verfügt über einen veröffentlichten Satz von „Änderungsregeln für Kompatibilität“, den Microsoft selbst bei der Entwicklung der .NET-Bibliotheken verwendet und der jede Änderungsart als erlaubt (✔️), verboten (❌) oder beurteilungsbedürftig (❓) klassifiziert.² Die Dokumentation stellt ausdrücklich fest, dass Sie sie unverändert als Kriterien für Ihre eigenen Bibliotheken übernehmen können, daher hier die wichtigsten Zeilen.

Es ist nicht so einfach wie COMs „Schnittstellen sind unveränderlich“, aber die zugrunde liegende Philosophie ist dieselbe: Eine öffentliche API ist ein Vertrag; Sie können den Vertrag erweitern, aber den bestehenden Vertrag nicht ändern. Und dass Änderungen wie das Hinzufügen einer virtuellen Methode oder das Umbenennen eines Parameters — Dinge, die auf den ersten Blick sicher aussehen — als Breaking Change klassifiziert werden, ist genau der Grund, warum Sie nach der Tabelle und nicht nach Gefühl urteilen sollten.

5.1 Starke Namen und drei Versionsnummern

.NET-Assemblies tragen mehrere Versionsnummern, jede mit einer anderen Rolle.¹⁰

• AssemblyVersion: die einzige Version, die die Laufzeitumgebung zur Identifizierung und zum Laden einer Assembly verwendet. Bei stark benannten Assemblies verlangt die CLR des .NET Framework eine exakte Übereinstimmung, sodass jede Erhöhung Aufrufer zwingt, eine Binding-Umleitung hinzuzufügen (.NET / .NET Core akzeptiert dagegen automatisch eine höhere Version). Um Umleitungen zu reduzieren, empfiehlt die offizielle Anleitung, nur die Hauptversion in AssemblyVersion widerzuspiegeln.
• FileVersion (AssemblyFileVersion): nur in den Dateieigenschaften des Explorers sichtbar, ohne Auswirkung auf das Laufzeitverhalten. Der empfohlene Ort, um eine CI-Build-Nummer einzustempeln.
• InformationalVersion: eine freiformatige, menschenlesbare Zeichenkette. Wird verwendet, um eine im Semver-Format formatierte Paketversion oder den Quell-Commit-Hash festzuhalten.

In der Praxis ist damit der funktionierende dreistufige Aufbau: Kompatibilität über die Paket-/Produktversion deklarieren (Semver), nur die Hauptversion in AssemblyVersion widerspiegeln und Builds mit FileVersion nachverfolgen.

6. Wie Sie Versionsnummern vergeben — Semver funktioniert erst mit einer „Definition“

Semantische Versionierung (Semver) passt in drei Zeilen: MAJOR bei einer inkompatiblen Änderung erhöhen, MINOR bei einer abwärtskompatiblen Funktionsergänzung, und PATCH bei einem abwärtskompatiblen Bugfix.⁵

Was sich leicht übersehen lässt: Die allererste Anforderung der Semver-Spezifikation ist, dass Software, die Semver verwendet, eine öffentliche API deklarieren muss.⁵ Ohne zu deklarieren, was als öffentliche API gilt, gibt es kein Kriterium dafür, was eine „inkompatible Änderung“ überhaupt ist, und ob die Hauptversion erhöht wird, hängt von der Tagesform der jeweiligen Person ab. An den meisten Stellen, an denen Semver in der Praxis nicht funktioniert, liegt das Problem nicht daran, wie die Nummern vergeben werden — sondern daran, dass diese Deklaration übersprungen wurde.

Ein realistisches Betriebsmodell für eine intern verteilte DLL sieht so aus.

1. Den Umfang der öffentlichen API deklarieren — bei einer nativen DLL sind das die exportierten Funktionen und öffentlichen Header, bei COM das IDL/die Typbibliothek, bei .NET öffentliche Typen und Member. Halten Sie ausdrücklich fest, dass „alles außerhalb davon ein internes Implementierungsdetail ist, das sich ohne Vorwarnung ändern kann“.
2. Eine Definition eines Breaking Change übernehmen — bringen Sie die Entscheidungstabellen dieses Artikels aus den Kapiteln 3 und 5, zusammen mit .NETs Änderungsregeln², als „unsere eigene Definition“ in Ihr Repository ein.
3. Die Prüfung automatisieren — für .NET können Werkzeuge wie Package Validation und ApiCompat die binäre Kompatibilität gegenüber der vorherigen Version mechanisch verifizieren.¹¹ Das eliminiert die „vermutlich passt schon“-Beurteilung während des Reviews.
4. Ein Kompatibilitätsfeld zu den Release-Notes hinzufügen — legen Sie jedes Mal ausdrücklich einen von drei Werten fest: kein Neubau nötig / Neubau empfohlen / Breaking Change enthalten. Das ist ein Mechanismus, um die Antwort auf „können wir die neue DLL einfach austauschen?“ schriftlich festzuhalten, bevor überhaupt jemand fragen muss.

7. Das Verfahren, wenn ein Kompatibilitätsbruch unvermeidbar ist

Erweist sich eine Änderung, die die Entscheidungstabelle als Breaking Change kennzeichnet, als unvermeidbar, gehen Sie so vor, dass Sie beide Versionen parallel anbieten, statt eine gegen die andere auszutauschen.

1. Alt und Neu parallel anbieten — bei COM heißt das, IFoo2 hinzuzufügen, während IFoo bestehen bleibt (Kapitel 4). Bei einer nativen DLL fügen Sie eine neue Funktion hinzu (FooEx) oder lassen eine neu benannte DLL neben der alten koexistieren. Bei .NET liefern Sie die Änderung als neues Paket mit erhöhter Hauptversion aus und halten die alte Hauptversion nur für Bugfixes am Leben.
2. Eine Übergangsfrist festlegen — in .NET kann das Attribut [Obsolete] eine Compilezeit-Warnung auslösen. Für nativen/COM-Code deklarieren Sie es über Header-Kommentare und Release-Notes, und legen Sie das geplante Entfernungsdatum ausdrücklich fest. Der Schlüssel ist, sich auf ein tatsächliches Datum festzulegen, nicht auf ein vages „wir entfernen es irgendwann“.
3. Bestandsaufnahme der Aufrufer machen — bauen Sie eine Liste, wer noch die alte API aufruft, indem Sie internen Quellcode durchsuchen, Installer-Verteilungsdatensätze prüfen und, bei COM, die Nutzung von Registrierungsreferenzen prüfen. Finden Sie ein Binary, das Sie nicht neu bauen können — ein Tool, das jemand gebaut hat, der inzwischen ausgeschieden ist, oder eine Drittanbieter-App —, verlängern Sie entweder die Lebensdauer der alten API speziell für diesen Fall, oder überbrücken Sie mit einem Wrapper.
4. Die alte API entfernen — erst nachdem die Bestandsaufnahme bestätigt hat, dass keine Aufrufer mehr übrig sind, entfernen Sie sie und erhöhen die Hauptversion.

Dieses Verfahren ist teuer. Genau deshalb ist paradoxerweise eine kleine API von der allerersten Version an mit der Entscheidungstabelle im Hinterkopf zu entwerfen — da alles, was Sie nie veröffentlichen, überhaupt keine Kompatibilitätsverpflichtung mit sich bringt — die größte Kompatibilitätsabsicherung, die Sie haben.

8. Zusammenfassung

• Denken Sie über Kompatibilität in drei Ebenen: binär, Quellcode und Verhalten. Die Verhaltenskompatibilität kann selbst ohne Neubau brechen.³
• Für native DLLs gilt: Hinzufügen ist sicher; einen bestehenden Export, eine Signatur oder ein Struct-Layout zu ändern ist ein Bruch. Geben Sie Structs ein cbSize-Feld, um Erweiterungsraum zu lassen.⁶
• Eine COM-Schnittstelle ist nach Veröffentlichung unveränderlich. Fügen Sie Änderungen als neue Schnittstelle mit neuer IID hinzu (IFoo2) und lassen Sie Aufrufer per QueryInterface unterscheiden.¹⁴⁷ Setzen Sie das besonders streng durch, wann immer früh gebundene VB6-/VBA-Clients beteiligt sind.
• Für .NET können Sie mit den offiziellen Kompatibilitätsänderungsregeln mechanisch urteilen. Achten Sie auf „scheinbar sichere“ Änderungen — virtual hinzufügen, einen Parameter umbenennen, einen Typ versiegeln —, die als Breaking Change klassifiziert werden.²
• Ein realistischer dreistufiger Aufbau: AssemblyVersion trägt nur die Hauptversion, FileVersion verfolgt den Build, und Semver deklariert die Kompatibilität.¹⁰
• Semver funktioniert erst, wenn Sie eine öffentliche API und eine Definition eines Breaking Change deklarieren.⁵ Übernehmen Sie die Entscheidungstabelle als diese Definition und prüfen Sie sie automatisch mit Werkzeugen wie Package Validation.¹¹
• Brechen Sie tatsächlich etwas, gehen Sie parallel anbieten → Übergangsfrist → Bestandsaufnahme → Entfernung. Niemals alles auf einmal auszutauschen, ist genau das, was die beim Kunden noch laufende alte EXE schützt.

Verwandte Artikel

• Was ist COM / ActiveX / OCX? — Unterschiede und Zusammenhänge gemeinsam erklärt
• Was ist COM — Warum das Design von Windows-COM auch heute noch trägt
• Eine typisierte .NET-8-DLL von VBA aus aufrufen — dscom und TLB
• Wie die Namensauflösung von Windows-DLLs funktioniert — Suchreihenfolge und SxS
• Was ist Reg-Free-COM? — COM ohne Registrierung nutzen
• Wie man eine C#-Native-AOT-DLL von C/C++ aus aufruft

Verwandte Beratungsbereiche

Die KomuraSoft LLC (合同会社小村ソフト) übernimmt das Kompatibilitätsdesign für DLLs, COM-Komponenten und .NET-Bibliotheken, auf die andere Systeme verweisen, die Bestandsaufnahme öffentlicher APIs und die Einrichtung einer Versionierungsrichtlinie sowie das Design und die Implementierung von Erweiterungen — das IFoo2-Muster, paralleles Anbieten —, die bestehende Clients nicht brechen.

• Nutzung vorhandener Ressourcen & Migrationsunterstützung
• Änderung & Wartung bestehender Windows-Software
• Technische Beratung & Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wenn ich einer DLL nur eine Funktion hinzufüge, müssen Aufrufer dann neu gebaut werden?

In der Regel nein — wird nur eine exportierte Funktion hinzugefügt, funktionieren bestehende Aufrufer unverändert weiter, da die Import-Auflösung weiterhin gelingt, solange Name, Signatur, Aufrufkonvention oder Export-Ordinalzahl einer bestehenden Funktion nicht geändert werden. Fügen Sie jedoch einem vom Aufrufer allozierten und übergebenen Struct ein Feld hinzu oder ändern Sie die Bedeutung des Rückgabewerts oder Fehlercodes einer bestehenden Funktion, kann die Verhaltenskompatibilität brechen, obwohl kein Neubau erzwungen wird. Die Grundregel lautet: Eine Funktion hinzuzufügen ist sicher, eine bestehende Signatur zu ändern ist ein Bruch.

Warum ist es verboten, einer COM-Schnittstelle nach der Veröffentlichung eine Methode hinzuzufügen?

Weil eine Schnittstelle gemäß der COM-Spezifikation nach ihrer Veröffentlichung unveränderlich ist. Die eigentliche Substanz einer Schnittstelle ist ein binärer Layout-Vertrag — die Vtable, eine geordnete Liste von Funktionszeigern —, und das Einfügen, Entfernen oder Umordnen von Methoden bedeutet, dass ein altes Binary an der zur Kompilierzeit fest einprogrammierten Slot-Position eine andere Methode aufruft. Ein Anhängen am Ende verschiebt zwar keine bestehenden Slots, führt aber eine neue Gefahr ein: Ein neuer Client kann eine alte Komponenteninstanz erhalten und annehmen, die angehängte Methode sei vorhanden, und dann einen Slot aufrufen, der dort in Wirklichkeit nicht existiert. Deshalb ist selbst ein Anhängen unter derselben IID nicht erlaubt. Wenn Sie Funktionalität hinzufügen möchten, fügen Sie eine neue Schnittstelle mit einer neuen IID hinzu (IFoo2) und lassen die bestehende IFoo unangetastet. Aufrufer können dann zur Laufzeit über QueryInterface sicher feststellen, ob sie mit der alten oder der neuen Schnittstelle sprechen.

Wie sollte ich AssemblyVersion, FileVersion und InformationalVersion in .NET unterschiedlich verwenden?

AssemblyVersion ist die einzige Version, die die Laufzeitumgebung zur Identifizierung und zum Laden einer Assembly verwendet; bei stark benannten Assemblies verlangt die CLR des .NET Framework eine exakte Übereinstimmung, sodass jede Erhöhung Aufrufer zwingt, eine Binding-Umleitung hinzuzufügen. Deshalb empfiehlt die offizielle Anleitung, in AssemblyVersion nur die Hauptversion widerzuspiegeln. FileVersion erscheint nur in den Dateieigenschaften des Explorers und hat keine Auswirkung auf das Laufzeitverhalten, was sie zu einem guten Ort macht, um eine CI-Build-Nummer einzustempeln. InformationalVersion ist eine freiformatige, menschenlesbare Zeichenkette, die verwendet wird, um eine im Semver-Format formatierte Version oder einen Commit-Hash festzuhalten.

Löst die Einführung semantischer Versionierung (Semver) Kompatibilitätsprobleme von allein?

Nein, Semver allein löst das nicht. Semver ist die Konvention, bei jeder rückwärtsinkompatiblen Änderung die Hauptversion zu erhöhen, setzt aber voraus, dass Sie bereits festgelegt haben, was als Ihre öffentliche API und was als Breaking Change gilt. Kleben Sie Versionsnummern auf Releases, ohne diese Definition, variiert die Beurteilung von Person zu Person, und das Schema funktioniert nicht mehr. Semver wird erst dann sinnvoll, wenn Sie so etwas wie die Entscheidungstabelle dieses Artikels (für native DLLs) oder Microsofts Kompatibilitätsänderungsregeln (für .NET) als Ihre eigene Definition eines Breaking Change übernehmen und diese Definition in Ihren Release-Prozess einbacken.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.