Я могу вспомнить, что при работе с MFC вы могли поддерживать несколько версий фреймворка MFC, проверив макрос _MFC_VER.
Сейчас я делаю кое-что с .NET 4 и хочу использовать Tuple в нескольких местах, но все равно сохраняю все, что совместимо с 3.5.
Я хочу сделать что-то вроде:
#if DOTNET4
public Tuple<TSource, TResult> SomeMethod<TSource, TResult>(){...}
#else
public KeyValuePair<TSource, TResult> SomeMethod<TSource, TResult>(){...}
#endif
Нет встроенных констант прекомпилятора, которые вы можете использовать. Но достаточно просто создать свои собственные конфигурации сборки в VS, причем каждая конфигурация имеет свой собственный набор определенных констант и, конечно же, целевую версию рамочной программы. Многие люди делают это, чтобы условно скомпилировать 32 или 64-разрядные различия.
Существует одно большое предостережение при определении пользовательских символов компиляции в вашем .csproj(или .vbproj, теоретически): они перезаписывают все ранее определенные символы компиляции. Например, рассмотрим фрагмент MSBuild:
<PropertyGroup Condition="'$(TargetFrameworkVersion)' == 'v4.0'">
<DefineConstants>$(DefineConstants);DOTNET_40</DefineConstants>
</PropertyGroup>
<PropertyGroup>
<DefineConstants>ITS_CLOBBERING_TIME</DefineConstants>
</PropertyGroup>
Второй элемент DefineConstants, как показывает его значение, скроет первое значение DefineConstants. Чтобы этого избежать, вы захотите переписать второй элемент DefineConstants, чтобы он выглядел следующим образом:
<DefineConstants>$(DefineConstants);ITS_CLOBBERING_TIME</DefineConstants>
Кроме того, вы захотите разместить это внутри PropertyGroup, определенного после всех других PropertyGroups, так как Visual Studio 2010 добавляет в пользовательские символы компиляции таким образом, что он будет клонировать любые другие пользовательские символы компиляции, которые вы определяете, если они перед тем, как Visual Studio отбросит свое определение. Я подал эту проблему в Microsoft. Вы можете отслеживать его прогресс на Microsoft Connect.
С другой стороны, ваш условный код компиляции может помешать программистам, которые его встречают.
Отредактировано на основе комментариев
Вероятно, лучше написать свой собственный класс, чтобы вы могли гарантировать, что он собирается делать, и у вас нет каких-либо странных проблем с сигнатурой или наследованием:
public class Pair<TSource, TResult>
{
public TSource Source { get; set; }
public TResult Result { get; set; }
public Pair() {}
public Pair(TSource source, TResult result)
{
Source = source;
Result = result;
}
// Perhaps override Equals() and GetHashCode() as well
}
Как всегда, полезно взвешивать, используя встроенный материал, и выкатывать свой собственный код. Обычно это означает, что вы спрашиваете себя: "Я поддерживаю и поддерживаю этот код?" vs. "Делает ли код то, что мне нужно, из коробки?"
В этом случае, поскольку у вас не будет Tuple<T1, T2>, я просто напишу свой собственный простой, чтобы другие разработчики могли легко дышать:)
Поскольку у вас должны быть разные проекты, вы можете иметь частичные классы и ссылаться только на тот, который вам нужен для каждого проекта, с конкретной логикой для них:
classname.cs public partial classname {...}
classname.40.cs public partial classname { public Tuple SomeMethod() {...} }
classname.35.cs public partial classname { public KeyValuePair SomeMethod() {...} }