.NET 3.5でコンパイルされた非同期ライブラリがありますが、.NET 3.5アプリケーションで使用されていますが.NET 4.0誰かが1つを渡そうとしている場合、CancellationTokens。.NET 4.0のものを含めるには、.NET 3.5との互換性を破る必要があります。私が今までに思いついた唯一のオプションは、 "オブジェクト"を渡してからリフレクションを使用することですが、それは醜いパブリックインターフェイスになります...クライアントコードが正しいものを渡していることを確認したい実行時ではなくコンパイル時のオブジェクト型。古いフレームワークバージョンで使用されているライブラリの新しい.NETフレームワーク機能をサポート
コンシューマアプリケーションに不要な依存性を導入することなく、コンパイル時に.NET 4.0オブジェクトに対してバインドする方法はありますか？ 「この機能がある場合はこの機能を使用し、そうでない場合はスキップしてください」と言います。
.NET 4.0タイプを別のアセンブリで、場合によっては拡張メソッドとして必要とするパブリックインターフェイスを持つことができます。また、必要に応じて（たとえば、.NET 4タイプと本体の内部）あなたは、メイン（.NET 3.5）アセンブリ内のインターフェイスを定義し、.NET 4アセンブリのラッパーを使用して.NET 4アセンブリに実装して、.NET 4タイプを反映させることができます。
私はこれが過渡的な問題を扱うので、私はこれが好きです。アセンブリXがアセンブリYを必要とし、アセンブリZが必要であり、Zが4.0を必要とする場合、XとYは4.0を必要とします。しかし、拡張方法では、Z 'は4.0のものを含み、Yは3.5のままであり、XはZ'を含めて4.0のものを使用することができます。主な欠点は、拡張メソッドで実装できる機能に限られていることです。 CancellationTokenRegistrationを少し面倒にすることはできますが、不可能ではありません。 –
CancellationTokenRegistrationを、（Yで定義された）インターフェースを実装するクラス（Z内）にラップします。 – Random832
いいえ、タイプをパブリックインターフェイスの一部にしたいので、2つの異なるバージョンをコンパイルする必要があります。 – adrianm
ライブラリの4.0バージョンと3.5バージョンを提案することは、もっと実用的かもしれません。 –
この#if！NET_3_5のような指令をステートメント#endifを使って使用すると、コード量を減らすことができます。これが良い方法であるかどうかはわかりません。 –