5

私のプロジェクトでは、依存関係の階層に問題があります。コードでライブラリ ( WriteableBitmapExtensions ) を使用しており、WriteableBitmapExtensions も使用する別のサードパーティ ライブラリがあります。他のライブラリのみが特定の古いバージョンに強く関連付けられており、私のコードには最新バージョンの機能が必要です。

依存関係の描写は次のとおりです。依存関係ツリー

同様の質問と解決策がありますが、構成ファイルを介して実行時にアセンブリをバインドすることで解決しますが、これは Silverlight アプリケーションと互換性があるとは思いません。

同じソリューションで 2 つの異なるバージョンの log4net を参照する

同じフォルダーで同じアセンブリの異なるバージョンを使用する

サードパーティのライブラリは、さまざまなバージョンの log4net.dll を参照しています

複数のバージョンの依存関係を処理するには?

では、Silverlight コンテキストでこれらの異なるバージョンのアセンブリ依存関係を解決する方法はありますか? ない場合、私のオプションは次のとおりです。

1) サードパーティのライブラリのベンダーに、WriteableBitmapExtensions の最新バージョンを使用するように更新するよう説得できる可能性が最も高いですが、最新の状態に保つことに依存したくありません。特に、WriteableBitmapExtensions プロジェクトはまだ更新されており、新しい機能を頻繁に利用しているためです。

2) WriteableBitmapExtensions はオープンソースであるため、そのソースを新しいアセンブリ "MyWriteableBitmapExtensions" として再コンパイルし、それをソース コードで使用できると思います。しかし、2 つのサードパーティ ライブラリが異なるバージョンの WriteableBitmapExtensions を参照している場合、この問題が再び発生します。

オプション 2 を使用すると思われますが、コミット/リファクタリングする前に、これを行うためのより良い方法 (他の質問のランタイム アセンブリ バインディングなど) があるかどうかを知りたいです。ありがとう！

4

1 に答える 1

1

コメントで述べたように、「v1」は実際には「プレベータ」バージョンであるため、オプション1はすぐに利用できるはずです。

サードパーティベンダーが非ベータバージョンを使用してビルドをリリースするのに遅れがある場合は、オプション2が次のオプションです。ビルドに完全に新しいIDを使用するようにしてくださいMyWriteableBitmapExtensions。具体的には、別のAssemblyName、FileName、Strong Name Signature、およびCOMを含むIDに使用されるGUIDを使用します。

新しい機能が必要ない場合、またはv2がv1と下位互換性がある場合でも、アセンブリバインディングが望ましいオプションです。これがSilverlightで利用できるかどうかは確認していませんが、そうでない場合は驚きます。ただし、 System.Configuration名前空間全体がSilverlightから欠落しているため（の2つの列挙を除くSystem.Configuration.Assemblies）、Silverlightでは実際のアセンブリバインディングがおそらく使用できないことに同意します。

それでも、別のオプションは、最新のソースコードを調整して、 v1と下位互換性のあるものを生成することです。必要に応じて、v2の機能を壊してしまう可能性があります。このようにして、v2の機能を引き続き使用できます。元のID（AssemblyName、FileName、Strong Name Signatureなど）を使用して再コンパイルします。そうすれば、両方のシナリオで1つのアセンブリを再び使用できるようになります。

于 2012-04-01T07:40:17.370 に答える