Auswirkungen von Codeänderungen auf Kompatibilität
Kompatibilitäts- bezieht sich auf die Fähigkeit, Code in einer anderen Version einer .NET Implementierung zu kompilieren oder auszuführen, als derjenigen, mit der der Code ursprünglich entwickelt wurde. Eine bestimmte Änderung kann sich auf sechs verschiedene Arten auf die Kompatibilität auswirken:
- Verhaltensänderung
- Binärkompatibilität
- Quellkompatibilität
- Entwurfszeitkompatibilität
- Abwärtskompatibilität
- Vorwärtskompatibilität (kein Ziel von .NET.NET Aspire)
Verhaltensänderung
Eine Verhaltensänderung stellt eine Änderung des Verhaltens eines Mitglieds dar. Die Änderung kann extern sichtbar sein (z. B. eine Methode kann eine andere Ausnahme auslösen), oder sie kann eine geänderte Implementierung darstellen (z. B. eine Änderung der Berechnung eines Rückgabewerts, das Hinzufügen oder Entfernen interner Methodenaufrufe oder sogar eine erhebliche Leistungsverbesserung).
Wenn Verhaltensänderungen extern sichtbar sind und den öffentlichen Vertrag eines Typs ändern, können sie leicht ausgewertet werden, da sie sich auf die binäre Kompatibilität auswirken. Implementierungsänderungen sind deutlich schwieriger zu bewerten; je nach Art der Änderung und der Häufigkeit sowie den Nutzungsmustern der API kann die Auswirkung einer Änderung von gravierend bis harmlos reichen.
Binärkompatibilität
Binäre Kompatibilität bezieht sich auf die Fähigkeit eines Nutzers einer API, die API in einer neueren Version ohne Neukompilierung zu verwenden. Änderungen wie das Hinzufügen von Methoden oder das Hinzufügen einer neuen Schnittstellenimplementierung zu einem Typ wirken sich nicht auf die binäre Kompatibilität aus. Das Entfernen oder Ändern der öffentlichen Signaturen einer Assembly, sodass Verbraucher nicht mehr auf dieselbe Schnittstelle zugreifen können, die von der Assembly verfügbar gemacht wird, wirkt sich jedoch auf die binäre Kompatibilität aus. Eine Änderung dieser Art wird als binäre inkompatible Änderungbezeichnet.
Quellkompatibilität
Die Quellkompatibilität bezieht sich auf die Fähigkeit bestehender Nutzer einer API, ohne Änderungen am Quellcode neu gegen eine neuere Version zu kompilieren. Eine inkompatible Änderung tritt auf, wenn ein Verbraucher den Quellcode ändern muss, der erfolgreich für eine neuere Version einer API erstellt werden muss.
Entwurfszeitkompatibilität
Die Entwurfszeitkompatibilität bezieht sich auf die Beibehaltung der Entwurfszeiterfahrung in allen Versionen von Visual Studio und anderen Entwurfszeitumgebungen. Dies kann zwar das Verhalten oder die Benutzeroberfläche von Designern umfassen, aber der wichtigste Aspekt der Entwurfszeitkompatibilität betrifft die Projektkompatibilität. Ein Projekt oder eine Lösung muss in einer neueren Version der Entwurfszeitumgebung geöffnet und verwendet werden können.
Abwärtskompatibilität
Rückwärtskompatibilität bezieht sich auf die Fähigkeit eines bestehenden Benutzers einer API, gegen eine neue Version zu arbeiten, während er sich auf die gleiche Weise verhält. Verhaltensänderungen und Änderungen der binären Kompatibilität wirken sich auf die Abwärtskompatibilität aus. Wenn ein Consumer nicht in der Lage ist, bei der Ausführung mit der neueren Version der API anders ausgeführt zu werden, wird die API abwärtskompatibel
Änderungen, die sich auf die Abwärtskompatibilität auswirken, werden nicht empfohlen, da Entwickler Abwärtskompatibilität in neueren Versionen einer API erwarten.
Vorwärtskompatibilität
Die Vorwärtskompatibilität bezieht sich auf die Fähigkeit eines vorhandenen Consumers einer API, mit einer älteren Version zu arbeiten und dabei dasselbe Verhalten beizubehalten. Wenn ein Consumer nicht in der Lage ist, bei der Ausführung mit einer älteren Version der API anders auszuführen oder zu verhalten, wird die API inkompatibleweiterleiten.
Die Aufrechterhaltung der Vorwärtskompatibilität schließt nahezu alle Änderungen oder Ergänzungen von Version zu Version aus, da diese Änderungen verhindern, dass ein Verbraucher, der auf eine spätere Version ausgelegt ist, in einer früheren Version läuft. Entwickler erwarten, dass ein Nutzer, der eine neuere API verwendet, möglicherweise nicht richtig mit der älteren API funktionieren könnte.
Die Aufrechterhaltung der Vorwärtskompatibilität ist kein Ziel von .NET.NET Aspire.
