.netバイナリ（dll）インターフェイスを壊すもの

Question

2つの.net dllを検討してください。最初の＆quot; application.dll＆quot;メインのビジネスロジックとデータアクセスコードが含まれています。 2つ目の「webservice.dll」既存のコードへのWebサービス呼び出しを提供する目的でapplication.dllを使用してオブジェクトとメソッドにリンクするWebMethodsで主に構成されます。

webservice.dllの再コンパイルを必要とせずにapplication.dllに変更できるものとできないもの（新しいクラスの追加、既存のクラスへの新しいフィールドやメソッドの追加など）

Answer 1

ほとんどの場合は問題ありません。それを壊すいくつかのこと：

• 使用されているタイプを削除*（タイプ転送を使用していない場合）
• 使用されている*削除メソッド（コンストラクターを含む）
• （使用される）メソッドの署名の変更
• パブリックフィールドをプロパティに変更する（使用される）
• シリアル化が使用されている場合のシリアル化内部の変更
• メソッドをインターフェイスに追加します。2番目のdllには、そのインターフェイスを実装する型があります
• 2番目のdllで継承される基本クラスへの抽象メソッドの追加
• ハックリフレクションが（ab）使用されている場合は、ほぼ内部的なもの
• 一般的な型/メソッドへの制約の追加
• 2番目のdllで継承されたタイプを sealed としてマークする
• 呼び出し元がコンストラクタの初期化ではなくメンバーごとの初期化を使用する場合、 struct にフィールドを追加します

（削除には、非公開のものへのアクセシビリティの変更が含まれます）

Answer 2

技術的には、名前はそれを壊します（強力な名前付きアセンブリの場合、名前とバージョン、およびキートークン）。それ以外の場合、フレームワークはDLLをロードして使用することを試します、これは異なるタイプまたはメソッドシグネチャ、欠落しているタイプなどに到達するまで、多少問題なく動作します。名前の使用は、DLLの地獄（またはその問題）に戻ります。

アイデアを得るには、アセンブリのバージョン管理の詳細を読むことをお勧めしますそのような問題を解決する方法。

Answer 3

新しいクラス、関数[application.dllに追加]を呼び出さない限り、webservice.dllを再コンパイルする必要なくapplication.dllに変更を加えることができます。 webservice.dllでapplication.dllの変更を消費する場合は、webservice.dllを再コンパイルする必要があります

もちろん、websrvice.dllによって使用されるapplication.dllのメソッドまたはプロパティのいずれかの署名またはアクセスレベルを変更すると、webserviceのコードが破損します。