私は、私のおもちゃプロジェクトの新しいマイナー リリースを作成中です。このプロジェクトは NuGet でリリースされ、.NET 4.0 以降と互換性があります。私が導入している新機能のいくつかは .NET 4.5 を必要とします (.NET 4.5 で導入された両方のインターフェースをユーザーが解決できる必要がありIReadOnlyCollection<T>
ますIReadOnlyList<T>
) が、プロジェクトを .NET 4.0 と互換性を保つ必要があります。最新の .NET フレームワークに簡単に移行できます。
したがって、私が直面している問題は、この「前方互換性」の問題を解決する方法です。私が考えた解決策は 2 つありますが、どちらもあまり魅力的ではないので、ここで誰かがアイデアやガイダンスを提供してくれることを願っています。
私が思いついた2つの解決策は次のとおりです。
解決策 1:#if
コンパイラ ディレクティブを使用し、.NET Framework バージョンごとに DLL をビルドし、NuGet パッケージを使用してそれらのバージョンを出荷し、プロジェクト サイトでダウンロードします。
この方法の欠点は、開発者が Visual Studio プロジェクトを .NET 4.0 から .NET 4.5 に更新するときに、(.NET 4.5 固有の機能を含む) .NET 4.5 バージョンを自動的に取得しないことです。これは最小の驚きの原則に違反しており、開発者が数か月後に機能を使用しようとすると、なぜ機能が機能しないのか頭が混乱することになります。
解決策 2: 1 つの DLL を使用し、現在のアプリ ドメインに存在する場合に両方の新しいインターフェイスを実装する型をオンザフライで発行します。これにより、単一の DLL をユーザーに配布でき、開発者がプロジェクトで .NET フレームワークのバージョンを切り替えたときに機能を利用できるようになります。これにより、物事が「うまくいく」ようになります。これは、私が現在向かっている方向です。
インターフェイスを実装する必要がある型を返す必要があるため、Reflection.Emit、ModuleBuilder、TypeBuilder などを使用して実行時にその型を作成する必要があるという欠点があります。これは非常に厄介なシズルです。しかし、それ以外にも、この型は新しい (匿名) アセンブリで作成する必要があるため、いくつかの内部型 (継承する必要がある型と実装する必要があるインターフェイス) を公開する必要があります。これらの内部型を公開すると、プロジェクトの API が汚染され、それらの型を変更できなくなります。
これらは私の選択肢だと思いますが、明らかな何かが欠けている可能性があります。だから私の質問は、私は可能性を見逃していますか? ソリューション 1 の問題を回避する方法はありますか、それともランタイム タイプの発行のハードコア ルートを使用する方がよいでしょうか?