Compiler Switch Deprecation/Removal Changes in Visual Studio “14”

Compiler Switch Deprecation/Removal Changes in Visual Studio “14”

Rate This
  • Comments 25

In the upcoming release of Visual Studio, we are making some changes to the Visual C++ compiler switches. Two areas are impacted by these changes, 1) projects built with certain variations of /clr and 2) projects using 32-bit compiler to detect 64 bit portability issues.

These changes are the outcome of our investigation of the usage rate, customer value and maintenance cost of legacy compiler switches.

What did we remove?

The compiler switches listed below have been marked as deprecated in previous releases of Visual Studio and will be removed in VS “14”.

  • /clr:oldSyntax: Tells the compiler to enable CLR functionality, using the old managed syntax, and to produce a mixed executable image. This has been deprecated since VS 2005.
  • /wp64 (and _w64): Tells the compiler to detect 64-bit portability problems on types that are also marked with _w64 keyword. This has been deprecated since VS 2010.

What did we deprecate?

 The compiler support of the following switches will be deprecated in VS”14” to be completely removed from the compiler in the next VS releases.

  • /clr:pure: Tells the compiler to enable CLR functionality and to produce a pure executable image (one that contains only MSIL).
  • /clr:safe: Tells the compiler to enable CLR functionality, to produce a pure executable image, and to only allow verifiable source code through the compiler.
  • This also involves the deprecation of C++ Libraries support of /clr:pure and /clr:safe.

Note: No changes are made to /clr. You can still use /clr switch to build your code. If you use /clr:pure or /clr:safe, you need to reconfigure your projects to build with /clr to produce mixed assemblies. If it is necessary to have pure managed assemblies, you need to port your code to C#.


Based on our analysis, we have decided to make these changes in VS "14" CTP1. We will continue to focus on the highest value features in the compiler such as the language conformance features which we have provided in loads in this CTP. If you have feedback, send it my way “”



Leave a Comment
  • Please add 2 and 4 and type the answer here:
  • Post
  • So does that mean that this bug is fixed?

    If I put the following code snippet in a project, and build it in the IDE, will I get a warning?

    int *ptr = 0;

    unsigned long num = (unsigned long) ptr; //should cause warnings 4311 and 4302

    Between 2005 - 2012, the only real way to get those warnings was to turn on /wp64 when targeting x64.  I agree that /wp64 when targeting i386 wasn't very valuable, but it was highly valuable when targeting x64.

  • @Ben Craig,

    How about you try it yourself with following steps:

    - Download the free Windows 8.1 VM:

    - Download the free VS2014 CPT (

    - Run VM and install VS2014 CPT in it.

    On a good internet connection and strong powerful machine, all this can be setup in less than 30 minutes (I dedicated 4 GB of RAM to the readymade VM from the aforementioned Internet Explorer website).

  • @Ben

    In VS2012 x64 compiler, you will get

    bug.cpp(3) : warning C4302: 'type cast' : truncation from 'int *' to 'unsigned long'

    In VS2013 x64 compiler, you will get

    bug.cpp(3) : warning C4311: 'type cast' : pointer truncation from 'int *' to 'unsigned long'

    bug.cpp(3) : warning C4302: 'type cast' : truncation from 'int *' to 'unsigned long'

    (4311 is the warning previously only given by /Wp64)

    Note that the above two warnings are off-by-default, so you need to explicitly enable them:

    #pragma warning(default:4302)

    #pragma warning(default:4311)

  • Aww. After VB.Net, C++/CLI was my next favourite language. Sad to see it going away for purely managed projects.

  • For my install of VS2012, the IDE doesn't use the 64-bit native compiler.  It uses the 32-bit compiler to cross compile to x64.  I have to explicitly enable those two warning with #pragma warning to get anything.

    C4302 is a level 2 warning, and C4311 is a level 1 warning.  I don't understand why these would be disabled by default for builds targeting x64.  The false-positive rate on these warnings is very low, and the kinds of bugs they detect tend to be difficult to diagnose at execution time.

  • This sounds reasonable, C++/CLI is a good way to interop with native code at a large scale (i.e. when maintaining so much PInvoke machinery it becomes impractical).

    The tooling in VS for .NET development in C# seems better than with C++/CLI, so if you're producing a purely managed assembly you might as well write it in C#.

  • Our enterprise applications need a reduced and decreasing set of .NET wrappers around com objects with each .NET version.   100% pure C# clr is our goal with no access or use of any com object.   This would address a large security and reliability problem we've had for 10+ years starting with .net 1.0

  • Could you please explain _why_ the /clr:pure and /clr:safe options are being deprecated, or point to a post where this is discussed? Mixed assemblies have a number of limitations that pure clr assemblies don't have (e.g. they target a specific processor architecture, they cannot be loaded from memory in to an AppDomain). So the ability to compile C++ code to pure clr is a useful (if not widely used) feature, and it would be nice to explain why this can no longer be supported.

  • Re "I don't understand why these would be disabled by default for builds targeting x64":

    Thanks for your feedback. Warning 4302 has been turned off by default since VS2005, and warning 4311 has been off since VS2013. I see your point though. As we start emitting these warnings without the need to /Wp64, I think it makes sense to revisit this design and reconsider the behavior.



  • @Nada Mohamed

    Yes, please reconsider this! Makes also sense in my opinion.

  • I agree with @Govert van Drimmelen, a *rationale* for the deprecation would certainly be useful!

  • This all seems very reasonable: I won't have any problems with any of it.

  • I think the rationale is: "too much burden to keep standard libraries pure/safe-compliant.

    We are being constantly reminded how /clr is great for interop scenarios. That basically means "don't use it for anything else".

    I think C++/CLI is also good for UI (in Windows Forms) in otherwise native C++ applications. The removal of WinForms project template in VS2012 was a bad decision.

    Using C# for user interface but C++ for everything else is not a good solution.

  • Getting the STL to work under /clr:pure is time consuming; when it's removed, that'll free up time to work on features and bugfixes.

  • Couldn't a less drastic measure be taken, like marking the STL as being incompatible for /clr:pure projects?

Page 1 of 2 (25 items) 12