17

これが私がやりたいことの具体的な例です。

string.Join関数を考えてみましょう。.NET 4.0 より前のバージョンでは、オーバーロードは 2 つしかなく、どちらもstring[]パラメーターが必要でした。

.NET 4.0 の時点で、より柔軟なパラメーターの型を取る新しいオーバーロードがありますIEnumerable<string>。

Join基本的に.NET 4.0関数が行うことを行う関数を含むライブラリがありますstring.Join。この関数の実装を、対象となる .NET フレームワークに依存させることができるかどうか疑問に思っていました。4.0 の場合は、単にstring.Join内部的に呼び出すことができます。3.5 以前の場合は、独自の内部実装を呼び出すことができます。

  1. この考えは理にかなっていますか？
  2. それが理にかなっている場合、それを行うための最も論理的な方法は何ですか? 4.0 よりも古い .NET バージョンを対象とする場合string.Join、IEnumerable<string>パラメーターを使用した への呼び出しはコンパイルさえされないため、プリプロセッサ ディレクティブが最も理にかなっていると想定しているだけだと思います。したがって、私が使用するアプローチは、コンパイルの前に行う必要があります。Environment.Version(たとえば、実行時にプロパティをチェックしても機能しません。)
4

3 に答える 3

15

プロジェクト ファイルの XML を介して条件付き定数を設定する方法を示すスタック オーバーフローに関する別の質問を見ることができます: コンパイル時にターゲット フレームワークのバージョンを検出する

次に、それを使用して、.NET 4 オーバーロードまたは独自のライブラリを使用する必要があるかどうかを判断できます。

于 2010-12-26T22:19:30.603 に答える
2

はい、それは理にかなっていると思います（変更が比較的小さいため、特定のケースでは）、明らかにそのようなことはかなり迅速に制御不能になる可能性があります.

私見ですが、最も論理的な方法は、バージョンごとに異なるソリューション/プロジェクト構成を作成NET40し、4.0 構成でカスタム シンボル (たとえば ) を定義し、それを#if. 構成でランタイム バージョンを変更できるかどうかはわかりませんが (これは明らかに完璧な解決策です)、最悪の場合はバージョンを手動で変更する必要があります。

編集:ジョシュアの回答にリンクされている回答を見たところ、より合理化されたソリューションのように思えますが、厳密に言えば質問に回答するので、とにかくここに残します。

于 2010-12-26T22:19:52.377 に答える
2

.NET 4.0 用のコードを準備し、フレームワーク検出に基づいて .NET 3.5 用の同様のコードを作成できます。

#if NOT_RUNNING_ON_4
public static class GuidExtensions
{
   public static bool TryParse(this string s, out Guid result)
   {
       if (s.IsNullOrEmpty())
           return null;
       try
       {
          return new Guid(s);
       }
       catch (FormatException)
       {
          return null;
      }
   }
}
#else
    #error switch parsing to .NET 4.0
#endif

そして、彼の行を *.csproj に入れます

<DefineConstants Condition=" '$(TargetFrameworkVersion)' != 'v4.0' ">NOT_RUNNING_ON_4</DefineConstants>
于 2014-08-06T12:11:47.290 に答える