By mckamey

2010-05-27 17:05:43 8 Comments

There are a few minor places where code for my project may be able to be drastically improved if the target framework were a newer version. I'd like to be able to better leverage conditional compilation in C# to switch these as needed.

Something like:

#if NET40
using FooXX = Foo40;
#elif NET35
using FooXX = Foo35;
#else NET20
using FooXX = Foo20;

Do any of these symbols come for free? Do I need to inject these symbols as part of the project configuration? It seems easy enough to do since I'll know which framework is being targeted from MSBuild.


How are people handling this situation? Are you creating different configurations? Are you passing in the constants via the command line?


@Kevinoid 2019-11-21 16:58:32

If you are using the .NET Core build system, you can use its predefined symbols (which actually match your example already and don't require any changes to your .csproj!):

#if NET40
using FooXX = Foo40;
#elif NET35
using FooXX = Foo35;
#else NET20
using FooXX = Foo20;

The list of predefined symbols is documented in Developing Libraries with Cross Platform Tools and #if (C# Reference):

.NET Framework: NETFRAMEWORK, NET20, NET35, NET40, NET45, NET451, NET452, NET46, NET461, NET462, NET47, NET471, NET472, NET48



@Nathaniel Roark 2012-10-05 00:14:08

I had problems with these solutions, possibly because my initial constants were pre-built by these properties.

<DefineConstants />

Visual Studio 2010 also threw up an error because of the semi-colons, claiming they are illegal characters. The error message gave me a hint as I could see the pre-built constants seperated by commas, eventually followed by my "illegal" semi-colon. After some reformatting and massaging I was able to come up with a solution that works for me.

  <!-- Adding a custom constant will auto-magically append a comma and space to the pre-built constants.    -->
  <!-- Move the comma delimiter to the end of each constant and remove the trailing comma when we're done.  -->
  <DefineConstants Condition=" !$(DefineConstants.Contains(', NET')) ">$(DefineConstants)$(TargetFrameworkVersion.Replace("v", "NET").Replace(".", "")), </DefineConstants>
  <DefineConstants Condition=" $(DefineConstants.Contains(', NET')) ">$(DefineConstants.Remove($(DefineConstants.LastIndexOf(", NET"))))$(TargetFrameworkVersion.Replace("v", "NET").Replace(".", "")), </DefineConstants>
  <DefineConstants Condition=" $(TargetFrameworkVersion.Replace('v', '')) >= 2.0 ">$(DefineConstants)NET_20_OR_GREATER, </DefineConstants>
  <DefineConstants Condition=" $(TargetFrameworkVersion.Replace('v', '')) >= 3.5 ">$(DefineConstants)NET_35_OR_GREATER</DefineConstants>
  <DefineConstants Condition=" $(DefineConstants.EndsWith(', ')) ">$(DefineConstants.Remove($(DefineConstants.LastIndexOf(", "))))</DefineConstants>

I would post a screenshot of the Advanced Compiler Settings dialog (opened by clicking the "Advanced Compile Options..." button on the Compile tab of your project). But as a new user, I lack the rep to do so. If you could see the screenshot, you would see the custom constants auto-filled by the property group and then you'd be saying, "I gotta get me some of that."

EDIT: Got that rep surprisingly fast.. Thanks guys! Here's that screenshot:

Advanced Compiler Settings

@zDougie 2015-02-27 03:39:28

Begin with clearing the constants:


Next, build up your debug, trace and other constants like:

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">

Last, build your framework constants:

<PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v2.0' ">
<PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v3.0' ">
<PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v3.5' ">
<PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v4.0' ">
<PropertyGroup Condition=" '$(TargetFrameworkVersion)' == 'v4.5' ">

I think this approach is very readable and understandable.

@ghanashyaml 2011-11-02 17:56:56

@Azarien, your answer can be combined with Jeremy's to keep it at one place rather than Debug|Release etc.

For me, combining both variations works best i.e. including conditions in code using #if NETXX and also building for different framework versions in one go.

I have these in my .csproj file:

    <DefineConstants Condition=" '$(TargetFrameworkVersion.Replace(&quot;v&quot;,&quot;&quot;))' &gt;= '4.0' ">NET_40_OR_GREATER</DefineConstants>
  <PropertyGroup Condition=" '$(TargetFrameworkVersion.Replace(&quot;v&quot;,&quot;&quot;))' == '3.5' ">

and in targets:

  <Target Name="AfterBuild">
    <MSBuild Condition=" '$(TargetFrameworkVersion.Replace(&quot;v&quot;,&quot;&quot;))' &gt;= '4.0' "
      RunEachTargetSeparately="true"  />

@Azarien 2011-10-25 11:29:40

In a .csproj file, after an existing <DefineConstants>DEBUG;TRACE</DefineConstants> line, add this:

<DefineConstants Condition=" '$(TargetFrameworkVersion.Replace(&quot;v&quot;,&quot;&quot;))' &gt;= '4.0' ">NET_40_OR_GREATER</DefineConstants>
<DefineConstants Condition=" '$(TargetFrameworkVersion.Replace(&quot;v&quot;,&quot;&quot;))' == '4.0' ">NET_40_EXACTLY</DefineConstants>

Do this for both Debug and Release build configurations. Then use in your code:

   // can use dynamic, default and named parameters

@Thanasis Ioannidis 2013-12-27 09:32:53

default and named parameters are not a feature of .NET framework 4, but a feature of .NET 4 compiler. They can be used also in projects targeting .NET 2 or .NET 3 as long as they are compiled in Visual Studio 2010. It is just syntactic sugar. On the other hand, dynamic is a feature of .NET framework 4, and you can't use it in projects targeting frameworks prior to this.

@Jeremy Cook 2010-12-16 04:44:41

An alternative that is working for me so far is to add the following to the project file:

    <DefineConstants Condition=" !$(DefineConstants.Contains(';NET')) ">$(DefineConstants);$(TargetFrameworkVersion.Replace("v", "NET").Replace(".", ""))</DefineConstants>
    <DefineConstants Condition=" $(DefineConstants.Contains(';NET')) ">$(DefineConstants.Remove($(DefineConstants.LastIndexOf(";NET"))));$(TargetFrameworkVersion.Replace("v", "NET").Replace(".", ""))</DefineConstants>

This takes the value of TargetFrameworkVersion property, which is like "v3.5", replaces the "v" and "." to get "NET35" (using the new Property Functions feature). It then removes any existing "NETxx" value and adds it to the end of the DefinedConstants. It may be possible to streamline this, but I haven't got the time to fiddle.

Looking on the Build tab of the project properties in VS you will see the resulting value in the conditional compilation symbols section. Changing the target framework version on the Application tab then changes the symbol automatically. You can then use #if NETxx preprocessor directives in the usual way. Changing the project in VS does not seem to lose the custom PropertyGroup.

Note that this doesn't give seem to give you anything different for the Client Profile target options, but that's not an issue for me.

@Greg Finzer 2011-06-15 11:56:38

Jeremy, wow thanks this is perfect since I am already building separately in my build solution.

@CAD bloke 2013-02-16 10:16:46

+1. Who'd have thought it would be so hard to find "$(DefineConstants.Contains('..." ?? Thanks

@David A. Gray 2017-02-21 18:46:02

I finally found my way to this page again, because I needed a refresher on how I got these magic constants into my build. I am today revisiting the same project, to subdivide the library, and I need the symbols to go with me into some of the subdivisions. I just looked above it, and noticed that your answer is already duly acknowledged in the original .CSPROJ file.

@Todd 2010-05-28 12:15:18

One of the best ways to accomplish this is to create different build configurations in your project:

<PropertyGroup Condition="  '$(Framework)' == 'NET20' ">

<PropertyGroup Condition="  '$(Framework)' == 'NET35' ">

And in one of your default configurations:

<Framework Condition=" '$(Framework)' == '' ">NET35</Framework>

Which would set the default if it wasn't defined anywhere else. In the above case the OutputPath will give you a separate assembly each time you build each version.

Then create a AfterBuild target to compile your different versions:

<Target Name="AfterBuild">
  <MSBuild Condition=" '$(Framework)' != 'NET20'"
    RunEachTargetSeparately="true"  />

This example will recompile the entire project with the Framework variable set to NET20 after the first build (compiling both and assuming that the first build was the default NET35 from above). Each compile will have the conditional define values set correctly.

In this manner you can even exclude certain files in the project file if you want w/o having to #ifdef the files:

<Compile Include="SomeNet20SpecificClass.cs" Condition=" '$(Framework)' == 'NET20' " />

or even references

<Reference Include="Some.Assembly" Condition="" '$(Framework)' == 'NET20' " >

@mckamey 2010-05-28 15:55:06

Perfect. I had just enough experience hacking the msbuild format to know it could be done, but not enough time to figure out all the details. Thank you very much!

@mckamey 2010-05-28 15:57:35

If you add a reference to this answer over on my related question (, I'll mark you as the solution there. This actually solves both of them at the same time.

@Akash Kava 2010-12-22 09:40:44

Thanks for answer, but now VS2010 already includes a new tag named "TargetFrameworkVersion" , now for each property group with condition, only TargetFrameworkVersion is changed, do we still need to all these to make it work?

@katbyte 2013-06-04 21:17:26

This answer isn't just about having defined constants for the framework but also building for multiple frameworks

@TheDev6 2014-05-05 06:23:12

This post worked for me but I'm not good at MSBuild and it took a while to figure it out. I made a project that works as an example.‌​zip

@Scott Rippey 2015-02-07 07:03:15

Wow, thank you so much for this answer! Immensely helpful!!! My single .csproj is now building v2.0, v3.5, and v4.0!

@David A. Gray 2015-06-09 07:07:46

I just applied the technique to two projects in VS 2013. Sweet!

@Dude0001 2015-07-02 12:50:14

Worked for me when building through VS. However, building the .sln with MSBuild called within a NAnt script, the 2nd build in <AfterBuild> was copying the output of the first build. The build log showed "Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files." It seems to me MSBuild decided to just copy the output from the first build because it thought nothing changed. I resolved this by adding in <AfterBuild> before the <MSBuild> line <Touch Files="File.cs" /> for one of the files in the project. This forced MSBuild to rebuild the 2nd build.

@Marco Alves 2016-01-28 14:33:13

Take a look at this link as well. Pretty explanatory.…

Related Questions

Sponsored Content

15 Answered Questions

[SOLVED] Embedding DLLs in a compiled executable

29 Answered Questions

[SOLVED] Fastest Way of Inserting in Entity Framework

4 Answered Questions

35 Answered Questions

7 Answered Questions

[SOLVED] Entity Framework 5 Updating a Record

8 Answered Questions

[SOLVED] Compile Views in ASP.NET MVC

3 Answered Questions

[SOLVED] Does C# compiler set version or platform constants?

Sponsored Content