私のソース コードは、.NET バージョン 1.1 と 2.0 の両方をサポートする必要があります。異なるバージョンをテストするにはどうすればよいですか?また、この状況に対処する最善の方法は何ですか?
コードの 2 つのセクションを別々のクラス、メソッドなどにインラインで配置する必要があるかどうか疑問に思っています。どう思いますか?
私のソース コードは、.NET バージョン 1.1 と 2.0 の両方をサポートする必要があります。異なるバージョンをテストするにはどうすればよいですか?また、この状況に対処する最善の方法は何ですか?
コードの 2 つのセクションを別々のクラス、メソッドなどにインラインで配置する必要があるかどうか疑問に思っています。どう思いますか?
ここにはさまざまなオプションがあります。私が働いている場所では #if プラグマを使用していますが、別のバージョンの別のアセンブリでも実行できます。
少なくとも、バージョンに依存するコードを別の部分クラス ファイルに保持し、コンパイル時に正しいバージョンを使用できるようにすることが理想的です。時間を遡ることができれば、これを強制します。現在、コード ベースには多くの #if プラグマがあり、管理が難しい場合があります。#if プラグマ全体の最悪の部分は、Visual Studio が現在の定義でコンパイルされないものをすべて無視するため、破壊的変更のチェックインが非常に簡単になることです。
NUnitは 1.1 と 2.0 の両方をサポートしているため、テスト フレームワークに適しています。NAntのようなものを使用して 1.1 と 2.0 のビルドを別々に作成し、NUnit テストを自動的に実行するのはそれほど難しくありません。
このようなことをしたい場合は、プリプロセッサ コマンドと条件付きコンパイル シンボルを使用する必要があります。
対象とする .NET のバージョン (NET11 や NET20 など) を明確に示すシンボルを使用し、関連するコードを次のようにラップします。
#if NET11
// .NET 1.1 code
#elif NET20
// .NET 2.0 code
#endif
単純な if/else ではなく、このようにする理由は、誰かがシンボルを定義するのを忘れた場合に備えて、追加の保護層です。
そうは言っても、これを行う/行う必要がある理由の核心まで掘り下げる必要があります。
この問題が発生したため、.NET v1.1 および v2.0 用のインターフェイスとユーティリティ コードの単一セットを実装する「互換性レイヤー」に行き着きました。
次に、インストーラーが適切なバージョンの適切なコードを作成しました。私たちはNSIS (無料!) を使用しました。NSIS には、.NET のバージョンを確認するために呼び出すことができる関数があります。
なぜ 2 つのコード ベースを維持する必要があるのかという質問をしたいと思います。
2 つのコード ベースを変更の数や変更の種類と同期させようとすると、非常に複雑になり、いずれかのバージョンをビルドするためのビルド プロセスも非常に複雑になります。