Is it possible to conditionally compile to .NET Framework version?

Question

I can recall back when working with MFC you could support multiple versions of the MFC framework by checking the _MFC_VER macro.

I'm doing some stuff now with .NET 4 and would like to use Tuple in a couple of spots but still keep everything else 3.5 compatible.

I'm looking to do something like:

#if DOTNET4
    public Tuple<TSource, TResult> SomeMethod<TSource, TResult>(){...}
#else
    public KeyValuePair<TSource, TResult> SomeMethod<TSource, TResult>(){...}
#endif

Answer 1

There are no builtin precompiler constants that you can use. But, it is easy enough create your own build configurations in VS with each configuration having its own set of defined constants and of course a target framework version. A lot of people do this to conditionally compile based 32 or 64 bit differences.

Answer 2

There is one big caveat to be aware of when defining custom compilation symbols in your .csproj (or .vbproj, theoretically): they overwrite all previously-defined compilation symbols. For example, consider MSBuild snippet:

  <PropertyGroup Condition="'$(TargetFrameworkVersion)' == 'v4.0'">
    <DefineConstants>$(DefineConstants);DOTNET_40</DefineConstants>
  </PropertyGroup>
  <PropertyGroup>
    <DefineConstants>ITS_CLOBBERING_TIME</DefineConstants>
  </PropertyGroup>

The second DefineConstants element will, as its value suggests, clobber the first value of DefineConstants. To avoid this, you'll want to rewrite the second DefineConstants element to look like this:

    <DefineConstants>$(DefineConstants);ITS_CLOBBERING_TIME</DefineConstants>

Also, you'll want to place this inside of a PropertyGroup defined after all other PropertyGroups, as Visual Studio 2010 currently adds in custom compilation symbols in such a way that it will clobber any other custom compilation symbols you define if they are placed before Visual Studio plops down its definition. I've filed this issue with Microsoft. You can track its progress at Microsoft Connect.

Answer 3

On a side note, your conditional compilation code will frustrate programmers that encounter it.

Edited, based on comments

It's probably better to write your own class so you can guarantee what it's going to do, and you don't have any weird signature or inheritance issues:

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
}

As always, it's good to weigh using the built-in stuff vs. rolling out your own code. Generally that means asking yourself, "Am I OK maintaining and supporting this code?" vs. "Does the code do what I need it to, out of the box?"

In this case, since you're not guaranteed to have Tuple<T1, T2>, I'd just write your own simple one so other developers can breathe easy :)

Answer 4

As you should have different projects, you could have partial classes and only reference the one you need for each project with the specific logic for them:

classname.cs public partial classname { ... }

classname.40.cs public partial classname { public Tuple SomeMethod(){...} }

classname.35.cs public partial classname { public KeyValuePair SomeMethod(){...} }