11

アセンブリclass Xのバージョン 1 があるとしますA.dll。

class X {
    SomeType Property { set; get; }
}

次に、アセンブリのバージョン 2 でA.dll:

class X {
    SomeType Property { set; get; }
    SomeType OtherProperty { set; get; }
}

ここで、XB.dllを読み込んで使用する 2 つ目のアセンブリがあるとします。プロパティを追加すると ABI が壊れますか? /の使用に失敗しますか? そうでない場合、宣言の順序に違いはありますか? プロパティが仮想であった場合、違いはありましたか?A.dllOtherPropertyB.dllA.dllX

私は本当に質問していると思います: 一般的な ABI ルールとは何ですか? 公開後にインターフェイスを変更するのは良くないことだとわかっていますが、サブクラスを追加せずに、一部のインスタンスでプロパティを追加できるようにしたいと考えています。

4

3 に答える 3

11

JIT コンパイラーは、変更が壊れていた場合のエラー メッセージの原因でもある、この多くのエラーを処理します。

ただし、DLL Hell と呼ばれる非常に危険なゲームをプレイしています。問題は、彼らがコードを再コンパイルしないことではなく、いつ再コンパイルするかです。彼らは最終的にそうするでしょう。微妙な間違いがあった場合、誰かが古いバージョンのインストーラーを実行したり、間違ったファイルをコピーしたりした場合、すべてが崩壊します。コードは実行されず、その理由を突き止めるのは不可能な仕事になります。これは、変更を行ってからずっと後に発生し、何が問題なのかを推測する方法もありませんし、彼らを助けることもできません.

[AssemblyFileVersion] と [AssemblyVersion] を上げてください。はい、後者を変更すると、再コンパイルする必要があります。または<bindingRedirect>、これも問題ありません。現在、追跡可能な記録があります。

ところで、これは .NET Framework でも発生しました。WaitHandle.WaitOne(int) はサービス パックに追加されましたが、[AssemblyVersion] の変更はありません。プログラマーは .NET 2.0 をターゲットにしましたが、ターゲット マシンに元の 2.0 がインストールされていた場合、コードは実行されませんでした。 非常に痛い。

于 2011-01-22T10:42:06.357 に答える
7

プロパティを追加しても問題ありません。

たとえば、自動的に番号が付けられた列挙型の途中に何かを追加すると、壊れるケースが 1 つあります。たとえば、ライブラリに次のコードがある場合:

enum Foo
{
   Bar,
   Qux
}

これを次のように変更します。

enum Foo
{
   Bar,
   Baz,
   Qux
}

次に、次のようなコードを再コンパイルする必要もあります。

if (foo == Foo.Qux)
{
    //  ...
}
于 2011-01-22T08:39:02.447 に答える
2

をアセンブリで使用するだけであれば、互換性が損なわれることはありませんB。ただし、アセンブリBがインターフェイスを実装するクラスを定義すると、そのクラスは新しく導入されたプロパティを実装しないため、壊れます。

于 2011-01-22T10:36:04.510 に答える