Why do native C++ projects have a TargetFrameworkV

Question

In Visual Studio (v100, v110) it is possible to specify the version of .NET framework that a project targets using the TargetFrameworkVersion element in the project file. (If there is no TargetFrameworkVersion element, the IDE just uses its default .NET version.) The specified TargetFrameworkVersion is then used to choose the (default) tool-chain which will be used to build the project.

The above is true for both CLR and native C++ projects. I find this really weird and confusing. If Visual Studio knows a project is native then why does it care what the TargetFrameworkVersion is?

Answer 1

Well, actually you'd have to ask the developers responsible for creating the MSBuild scripts, because in principle it is not really needed, nor used. And they know it themselves. For a standard C++ project file, these are the lines causing the property to get set (Microsoft.Common.targets):

  <!-- By default, we are creating a managed app because .NET 2.0 projects did not have this property. -->
  <PropertyGroup Condition="'$(TargetRuntime)' == ''">
    <TargetRuntime>Managed</TargetRuntime>
  </PropertyGroup>

  <!-- Because .NET 2.0 apps did not set TargetFrameworkIdentifier, we need to set it for them here by default. If
       the runtime is set to Managed, we also need to set these.  Otherwise they should be blank (for instance Javascript or
       Native apps) because they do not target a .NET Framework. -->
  <PropertyGroup Condition="'$(TargetRuntime)' == 'Managed'">
    <TargetFrameworkIdentifier Condition="'$(TargetFrameworkIdentifier)' == ''">.NETFramework</TargetFrameworkIdentifier>
    <TargetFrameworkVersion Condition=" '$(TargetFrameworkVersion)' == '' ">v4.0</TargetFrameworkVersion>
  </PropertyGroup>

Answer 2

Lazy programming, basically. Microsoft historically preferred managed code because it's not really portable to other operating systems, causing lock-in. So the .NET languages have had more priority in Visual Studio.