In this post I will show you how you can use MSBuild to target your project for .NET 3.5 or .NET 4.0 and use a separate app.config file for each.
My Warmup Tool is supposed to work with SP2010 and SP2013. To achieve that compatibility, I have to change the TargetFramework of the project to be able to compile, as well as the app.config so the application uses the desired Framework. I didn’t want to change the values every time manually. An automated solution has to be possible. And it is. Some little changes to the project file and MSBuild will do all the work for you
So lets look into the default .csproj file, which sets the TargetFramework and references the app.config.
1: <?xml version="1.0" encoding="utf-8"?>2: <Project DefaultTargets="Build" xmlns="http://..." ToolsVersion="4.0">3: <PropertyGroup>4: <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>5: <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>6: ...7: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>8: ...9: </PropertyGroup>
The version has to be exchanged, because SharePoint 2013 uses the .NET Runtime 4, but SP 2010 the Version 2. Trying to build the project with the wrong Target Framework will fail. The referenced SharePoint Assemblies depend on the correct Framework Version.
An easy way to specify the value depending on a condition, is to use the Constants, you can define on the build page within the project settings.
I use “SP2010” and “SP2013”, which can be used by MSBuild. You can change that value any time. Reloading the project is not necessary, as the Build-process picks up the value when it needs it.
Let’s get back to the TargetFramework. Switching the version depending a constant defined (“SP2013” in my case) is done with two new property groups in the csproj file of your project. I’ve included the lines below the debug/release Property Groups, because the DefineConstants property is defined there.1: <PropertyGroup Condition=" $(DefineConstants.Contains('SP2010')) ">2: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>3: </PropertyGroup>4: <PropertyGroup Condition=" $(DefineConstants.Contains('SP2013')) ">5: <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>6: </PropertyGroup>
Remove the default entry, which is the one you see on line 7 of the previous code fragment above.
Now we are set up, and may compile the project for .NET 3.5 and .NET 4.0. Great. To have the application config include the supportedRuntime version as well, I’ve included two config files into my project.
The files are identical, except the value of the supportedRuntime, which is v2.0.50727 for .NET 3.5 and v4.0.30319 for .NET 4.0. Again MSBuild is your friend for using one or the other file depending the previously used constant “SP2010” or “SP2013”.
The switching condition can be specified like this:1: <ItemGroup Condition="$(DefineConstants.Contains('SP2010'))">2: <None Include="Config\2010\app.config" />3: </ItemGroup>4: <ItemGroup Condition="$(DefineConstants.Contains('SP2013'))">5: <None Include="Config\2013\app.config" />6: </ItemGroup>
The default entry for including the root-level app.config file has been removed from the csproj file.
As a result of the effort, I can build my console application for SharePoint 2010 and SharePoint 2013 by switching the constant in the project settings. The corresponding app.config file is used as well.