破壊的変更のカテゴリBreaking change categories

"互換性" とは、コードが最初に開発されたときのものとは異なる .NET 実装のバージョンで、コードがコンパイルまたは実行できることを指します。Compatibility refers to the ability to compile or execute code on a version of a .NET implementation other than the one with which the code was originally developed. 特定の変更があると、6 つの異なる方法で互換性に影響する場合があります。A particular change can affect compatibility in six different ways. 互換性を評価するときに考慮される変更の個々の種類は、次の 5 つのカテゴリに分類できます。The individual kinds of changes that are considered when evaluating compatibility fall into the following categories:

動作の変更Behavioral change

動作の変更とは、メンバーの動作の変更を指します。A behavioral change represents a change to the behavior of a member. この変更は、外部から参照可能 (たとえば、メソッドが別の例外をスローするなど) である場合があります。または、変更された実装 (たとえば、戻り値の計算方法の変更、メソッドの内部呼び出しの追加または削除、またはパフォーマンスの大幅な向上など) を指す場合があります。The change may be externally visible (for example, a method may throw a different exception), or it may represent a changed implementation (for example, a change in the way a return value is calculated, the addition or removal of internal method calls, or even a significant performance improvement).

動作の変更が、外部から参照可能、かつ型のパブリック コントラクトを変更するものである場合、バイナリの互換性に影響するため、簡単に評価できます。When behavioral changes are externally visible and modify a type's public contract, they are easy to evaluate since they affect binary compatibility. 実装の変更の評価はさらに困難です。変更の性質、および API の使用の頻度およびパターンによって、変更の影響は深刻なものから無害なものにまで及びます。Implementation changes are much more difficult to evaluate; depending on the nature of the change and the frequency and patterns of use of the API, the impact of a change can range from severe to innocuous.

バイナリの互換性Binary compatibility

バイナリの互換性とは、API のコンシューマーが、再コンパイルせずに新しいバージョンで API を使用できることです。Binary compatibility refers to the ability of a consumer of an API to use the API on a newer version without recompilation. 型へのメソッドの追加または新しいインターフェイス実装の追加などの変更は、バイナリの互換性には影響しません。Such changes as adding methods or adding a new interface implementation to a type do not affect binary compatibility. しかし、アセンブリによって公開されるインターフェイスと同じものにコンシューマーがアクセスできなくなるように、アセンブリのパブリック シグネチャが削除または変更されると、バイナリの互換性が影響を受けます。However, removing or altering an assembly's public signatures so that consumers can no longer access the same interface exposed by the assembly does affect binary compatibility. このような種類の変更は、"バイナリ非互換な変更" と呼ばれます。A change of this kind is termed a binary incompatible change.

ソースの互換性Source compatibility

ソースの互換性とは、API の既存のコンシューマーが、ソースを変更せずに新しいバージョンに再コンパイルできることを指します。Source compatibility refers to the ability of existing consumers of an API to recompile against a newer version without any source changes. "ソース非互換な変更" は、コンシューマーが新しいバージョンの API が正しくビルドされるように、ソース コードを変更する必要がある場合に発生します。A source incompatible change occurs when a consumer needs to modify source code for it to build successfully against a newer version of an API.

デザイン時の互換性Design-time compatibility

デザイン時の互換性とは、デザイン時のエクスペリエンスを Visual Studio の複数のバージョン間およびその他のデザイン時環境で維持できることを指します。Design-time compatibility refers to preserving the design-time experience across versions of Visual Studio and other design-time environments. デザイン時の互換性には、デザイナーの動作または UI も含まれる場合がありますが、プロジェクトの互換性が最も重要です。While this can involve the behavior or the UI of designers, the most important aspect of design-time compatibility concerns project compatibility. プロジェクトまたはソリューションは、そのデザイン時環境の新しいバージョンで開いて使用できる必要があります。A project or solution must be able to be opened and used on a newer version of the design-time environment.

下位互換性Backwards compatibility

下位互換性とは、API の既存のコンシューマーが、新しいバージョンに対して同じ動作で実行できることを指します。Backwards compatibility refers to the ability of an existing consumer of an API to run against a new version while behaving in the same way. 動作の変更とバイナリの互換性の変更の両方が、下位互換性に影響します。Both behavioral changes and changes in binary compatibility affect backwards compatibility. コンシューマーがその API の新しいバージョンで実行されるときに、実行できない、または動作が異なる場合、その API は "下位非互換" です。If a consumer is not able to run or behaves differently when running against the newer version of the API, the API is backwards incompatible.

開発者は新しいバージョンの API が下位互換であることを期待しているので、下位互換性に影響する変更は行わないことを推奨します。Changes that affect backwards compatibility are discouraged, since developers expect backwards compatibility in newer versions of an API.

上位互換性Forward compatibility

上位互換性とは、API の既存のコンシューマーが、古いバージョンに対して同じ動作を示して実行できることを指します。Forward compatibility refers to the ability of an existing consumer of an API to run against an older version while exhibiting the same behavior. コンシューマーがその API の新しいバージョンで実行されるときに、実行できない、または動作が異なる場合、その API は "上位非互換" です。If a consumer is not able to run or behaves differently when run against an older version of the API, the API is forward incompatible.

上位互換を維持するということは、バージョン間でどのような変更や追加も実質的に行わないことを意味します。より新しいバージョンを対象とするコンシューマーが以前のバージョンで実行されるのを、これらの変更が阻止するためです。Maintaining forward compatibility virtually precludes any changes or additions from version to version, since those changes prevent a consumer that targets a later version from running under an earlier version. 開発者は、より新しい API に依存するコンシューマーが古い API では正しく動作しない場合があると想定しています。Developers expect that a consumer that relies on a newer API may not function correctly against the older API.

上位互換性の維持が .NET Core の目標ではないのです。Maintaining forward compatibility is not a goal of .NET Core.

関連項目See also