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;
#endif
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.
/p:DefineConstants="NET40"
How are people handling this situation? Are you creating different configurations? Are you passing in the constants via the command line?
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;
#endif
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
.NET Standard:
NETSTANDARD
,NETSTANDARD1_0
,NETSTANDARD1_1
,NETSTANDARD1_2
,NETSTANDARD1_3
,NETSTANDARD1_4
,NETSTANDARD1_5
,NETSTANDARD1_6
,NETSTANDARD2_0
,NETSTANDARD2_1
.NET Core:
NETCOREAPP
,NETCOREAPP1_0
,NETCOREAPP1_1
,NETCOREAPP2_0
,NETCOREAPP2_1
,NETCOREAPP2_2
,NETCOREAPP3_0
I had problems with these solutions, possibly because my initial constants were pre-built by these properties.
<DefineConstants />
<DefineDebug>true</DefineDebug>
<DefineTrace>true</DefineTrace>
<DebugSymbols>true</DebugSymbols>
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.
<PropertyGroup>
<!-- 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>
</PropertyGroup>
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:
An alternative that is working for me so far is to add the following to the project file:
<PropertyGroup>
<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>
</PropertyGroup>
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With