Framework Multi-Targeting for VC++ Projects

Framework Multi-Targeting for VC++ Projects

  • Comments 18

Pavan (2)Short Bio: Pavan Adharapurapu is a developer on the Visual Studio Project and Build team. As part of VS 2010, he has worked on numerous features of the VC++ project system such as property sheets, filters, property pages, platform and tool extensibility, etc. His long term focus is on developing a "common project system" infrastructure which could be used to quickly build richly featured project systems. Prior to joining the Visual Studio team in 2008, he was working on Workflow technologies in Microsoft Dynamics Axapta. Pavan holds a Masters degree in Computer Science (CS) from the University of California, Los Angeles (UCLA) and a Bachelors degree in CS from the Indian Institute of Technology (IIT), Madras. He lives in Redmond, WA with his wife and loves to play soccer and watch movies in his spare time.

Have you ever wanted to target .NET Framework 3.5 with your C++ application in Visual Studio 2010? If you’ve upgrade your C++ CLR application or created a new one, you will notice that it automatically will target .NET Framework 4.0. However, with a little bit of work it is possible to have your C++ CLR application developed in VS 2010 and targeting 3.5. This blog post will explain just that. Please note that this post is about managed re-targeting for VC++ projects as opposed to

· Managed re-targeting for C#/VB projects (see ScottGu's blog post for this), or

· Native re-targeting for VC++ projects (Li’s blog post on the VC++ blog and Soma's blog post).

I assume that you have a VS 2010 VC++ CLR project (.vcxproj) generated, perhaps, by the Visual Studio Conversion Wizard that you want to re-target to v3.5 framework version. Note that you can see the current framework version targeted by this project by going to the project properties UI and looking under Common Properties > Framework and References for the Targeted framework property (see snapshot below).

clip_image002

This field was a drop-down in VS 2008 and was the primary way one could re-target to a different framework version. In VS 2010, it is a read-only field. To re-target in VS 2010, we need to do some work.

First of all VS 2008 SP1 must be installed on your system (you cannot do without SP1). This is a mandatory requirement for targeting framework version 3.5. Installing only the .NET Framework 3.5 redist won't do. C++ tools like cl.exe in VS 2010 are only capable of targeting v4.0. So to target an earlier framework version, we need the tools from that earlier version. And these tools are shipped with VS and not with .NET Framework.

Next, you need to manually edit the project file (.vcxproj) with a text editor (like notepad) and add the TargetFrameworkVersion property (if it is not already there) as shown below. It is recommended that this property be added to the property group labeled "Globals".

image

If you use VS IDE itself to edit the project file (you have to first Unload Project and then choose Edit MyProject.vcxproj from the context menu of the project in the solution explorer), you will get the very helpful intellisense (see picture below) that will aid you in the definition of this property.

clip_image005

Once this property is defined with the right value, reload the project and verify that the Targeted framework property mentioned at the beginning of this post shows v3.5.

Leave a Comment
  • Please add 4 and 4 and type the answer here:
  • Post
  • Does that sounds sane to anyone? No?

    "But it's ok! We've got Intellisense!"

    ={

  • Are there are any known issues with developing managed C++/CLI targeting 3.5 in Visual Studio 2010? If not, why doesn't VS have an option for this, like every other managed language?

  • I appreciated the tip but I hope this is a temporary situation for the beta.

    It should be an easy switch in the final project right?

  • Yes, the blog post is intended as a tip on how to retarget a C++/CLI project even if there is no support in the C++ Project System for that.

    I want to clarify a few points though: there is no known limitation in C++/CLI when targeting CLR 2 based .NET versions and the C++ build system completely supports this scenario (provided that you have VS2008 SP1 installed side-by-side on that machine). The missing functionality is the ability to retarget from the IDE.

    The previous release of VC++ (2008) used to have a dropdown to retarget directly from the C++ property pages but in this release we decided to remove this functionality. As I commented in this forum post [1], this decision was mainly made because of resource constraints and the fact that we prioritized native development higher. As such, we focused on delivering a good native multi-targeting story instead.

    There is no argument that for managed developers, this new behavior does not match the convenience of a dropdown for retargeting, but the belief is also that retargeting is a rare action (maybe even a one-time action) and with proper instructions (like Pavan's above), developers will be able to avoid the pain caused by this missing feature.

    We are interested in hearing your feedback and if you feel that this is hindering your development experience, I'd love to understand your scenario better and how we can address it now and in the future.

    Thanks,

    Marian Luparu

    Visual C++ Team

    [1]: http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/85366e16-7719-4e36-942f-a46d8d0996e5

  • I would like to thank the C++ team for removing features from the new version. VS2010 RTM is out and the C++ language has gone backward again. The GUI doesn’t support changing the targeted version. Thank you for that. I have found that Basic has always been far superior to C. With the co-evolution strategy of VB.NET, F#, C# IronPython, and IronRuby beginning, seems like languages like VB6 and C++ will soon be placed in the Smithsonian along with Sanskirt. Why do some hang so tightly to languages?

  • Having since loaded the VS2010 RTM, here again is another hit to C++/CLI support.

  • So if you're breaking multitargeting at one place why support it in the first place??? In grown applications -- as in mine -- you have dependencies to different projects build with different languages.

    My case:

    C# (.Net 2.0, Huge library) -> C++ (.Net 2.0, Very small, convenient tool).

    So, I imported into VS 2010, and can't compile any more as my c#-library has a lower .net-version, and no chance to fix this without installing VS 2008, which is not available.

    So, no transformation to VS 2010 without the need to migrate the library the .Net 4.0 (not possible) or to reimplement the c++ tool, which takes time.

    So, please, please, support multitargeting from within VS 2010, or provide alternate ways of installing the feature without VS 2008.

  • super big thx:)

  • Hello.

    I think I've managed to wrap up a support for VS2003. You might like to check it at vs2003.blogspot.com .

  • U r my hero of the hour!!

  • Some people have mentioned compiler crashes when using Net 3.5 with VS2010 in this way (when using VS90 compiler for C++). Some get this crash when they haven't before with VS 2008.

    social.msdn.microsoft.com/.../04b94942-7c24-4632-be45-4f0452ef699b

    connect.microsoft.com/.../compiler-crash-related-to-system-core-and-string

  • This is really bad. This results in having multiple c++ runtimes. And apparently they are not compatible. I have c++ library returning an std::string, linked against v100. This library is used in a managed c++/CLI library, framework 2.0 toolset v90. The string that is returned generates a crash, and when expanding the contents of the string in VS2010, VS2010 crashes. (Apparently because it contains over 1million entries)... The address of the returned std::string::c_str() was 0xFFFFFFF. When I drop the requirement of framework 2.0 and move to 4.0 everything works OK again. Or alternatively keep using toolset v90 for all libraries.

  • We have complicated legacy C/C++ back end modules called from C#. For a variety of system wide compatibility concerns we want to use VS2010 and stick with .NET 3.5, ie we cannot blindly go up to the next .NET framework. I cannot imagine this situation is unique. Without blogs like this + google to find them, we would have been stuck for ever.

  • ..in addition to which we have trouble keeping track of C/C++ runtimes installed in the field, on 32 and 64 bit systems. Our application is complex in its installation needs. So again - it makes sense to stick to .NET 3.5 and the m*90.dll's for run-times even tho' we want to use VS2010 for development.

  • I followed these instructions to the letter. Here's the result:

    1>c:\program files (x86)\microsoft visual studio 9.0\vc\include\msclr\marshal.h(49): fatal error C1001: An internal error has occurred in the compiler.

    1>  (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x5B0BE0DB:0x00000030]', line 182)

    1>   To work around this problem, try simplifying or changing the program near the locations listed above.

    1>  Please choose the Technical Support command on the Visual C++

    1>   Help menu, or open the Technical Support help file for more information

    More good work....

Page 1 of 2 (18 items) 12