Change C++/CLI project to another framework than 4.0 with vs2010
Yes it is possible to change the target even for managed C++ projects:
Changing the Target .NET Framework for C++/CLI (VS 2010) To change the version of the .NET Framework for C++/CLI projects (VS 2010)
Right click on project in Solution Explorer and click Unload project Right click on unloaded project in Solution Explorer and select Edit
<projectname>.vcxproj
In project XML file locate node<PropertyGroup Label="Globals">
In that node locate node<TargetFrameworkVersion>
(if the node cannot be found, add it) Inner text of the node defines target framework. It can be v2.0,v3.0, v3.5 or v4.0 Save vcxproj file and close it Right click on unloaded project in Solution Explorer and click Reload Project Example<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
Note: These steps apply only for Visual Studio 2010 as it uses new format of C++ project files.
Source on MSDN: How to: Change the Target .NET Framework
This shows up when you press F1 in the Framework and References dialog:
By default for new projects, the targeted framework is set to .NET Framework 4. The IDE does not support modifying the targeted framework, but you can change it manually. In the project file (.vcxproj), the default targeted framework is represented by the v4.0 property element. To change the targeted framework, unload the project, use a text editor to open the project file, and then change the value of the property element from v4.0 to another version that is installed on your server. For example, if you specify v3.5, which represents the .NET Framework v3.5, Visual Studio 2008 SP1 must be installed. Save and close the file, reload the project, and verify that the targeted framework is displayed in the property page.*
That's not terribly accurate on converted projects, you'll have to add the <TargetFrameworkVersion>
element yourself. Put it in the PropertyGroup labeled "Globals":
<PropertyGroup Label="Globals">
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
<others...>
</PropertyGroup>
The story is different when you use VS2012 and up, the first version of VS that acquired the Platform Toolset setting in the General property page. You must then select "v90" to get a proper build that targets 3.5. It is however clumsy, you must have all intermediate versions of VS installed on the machine to have that selection available.
Why you need VS2008 installed requires an explanation by itself. The core issue is that the C runtime library (msvcrt100.dll and up) contains .NET code to support managed code execution. The crucial detail is a module initializer that ensures the CRT is correctly initialized in program that uses C++/CLI code. That code always targets .NET 4 and since it is hard-baked into msvcrt100.dll (and up) you always have a rock-hard dependency on the v4.0.30319 runtime. You can only ever have a pure v2.0.50727 dependency when you use the old C runtime, msvcrt90.dll. You can only be sure that you have a msvcrt90.dll dependency when you use the compiler's #include files of VS2008.
Cold hard fact that it is pretty necessary to move to .NET 4 soon, you'll struggle with build problems like this if you don't. There are very few practical obstacles to that, .NET 4 is widely available for free on all targets you'd imagine. Overcoming the FUD that is associated with moving to a higher runtime version is generally only the real issue. No reasons for fear and doubt, it is stable.
by an anonymous user:
(Editing as I am a new user and cannot respond to this, whomever sees this feel free to submit the following) Changing the Toolset to v100 actually causes VS2010 to target .NET 4.0, even though it will still show up as targetting 3.5 in the project properties. VS2010 should really spit out a warning about this, because currently it appears as you though you can target .NET 3.5 with the v100 toolset, which you can't.