MicrosoftDotNet version of VisualCeePlusPlus developed by MicrosoftCorporation. Officially known as ''C++ with Managed Extensions''.

It came out in 2003 together with the DotNet 1.1 release where there are many extensions to support mobile and smart devices. This is the tool to use for making DotNet applications that require to communicate with non''''''DotNet capable computing devices. 

Other names for this product include VisualCeePlusPlus''''''2003, Managed Extensions for C++. A Microsoft roadmap for this product can be found at http://support.microsoft.com/default.aspx?scid=kb;en-us;310559 

Differences between ManagedCeePlusPlus and ANSI C++ (the following statements are true for Managed C++ and false for standard C++). Many of these differences are needed to support the CommonLanguageRuntime efficiently, others correct (perceived) inadequacies in C++.

* No MultipleInheritance
* GarbageCollection

<please fill in the blanks>

In some sense, Managed C++ is provided to enable the user to port legacy C++ apps to the DotNet platform; it appears that MS would prefer that new code be written in either VisualBasicDotNet or CsharpLanguage. 

*''Unless one needs high performance, create ComComponent objects of the now expired DistributedInternetArchitecture so EnterpriseServices (ComPlus) can function, interact with DotNetCompactFramework, etc etc''

----
'''From Everett to Whidby'''

http://www.fawcette.com/vsm/2002_08/online/pmeader_08_26_02/

Now that we know what Everett is like, though ManagedCeePlusPlus, are there better information on the impact of Whidby to CeePlusPlus landscape?

----
'''Why use ManagedCeePlusPlus'''

You can mix managed C++ and unmanaged C++ in the same application. You can call managed C++ from C# and you can call regular C++ from managed C++ all in the same application. You cannot, however, directly call from C# to unmanaged C++, but it is pretty easy to put in a managed C++ wrapper. My understanding (which might be incorrect, perhaps an expert should jump in) is that Visual C++.NET can compile unmanaged (i.e. "regular") C++ to IL. However, unmanaged C++ doesn't comply with the CLS ("common language specification?"), which is what would allow direct interoperability between it and a managed language such as C# or Visual Basic.NET. Managed C++ does comply with the CLS, and it is interoperable with the other .NET languages, and conveniently, managed C++ is interoperable with regular C++ as well. Note that there are security implications if you mix C++ and a managed language since the CLR can't make the same security guarantees for C++ code as it can for the managed languages like C#. -- CurtisBartley

''Curtis is right - Managed C++ (or, rather, "C++ with managed extensions") ''does'' support multiple inheritance (in the sense that classes that use multiple inheritance can be compiled down to IL), but such classes are not "managed code", and they operate independently of the garbage collector, and generally work just like native C++ classes. When you mark a class as __gc, then it becomes a managed type, and participates in the CLR object model (with all the differences from the native C++ object model that that entails). If all you want out of managed C++ is the ability to call managed libraries, then it's as easy as compiling existing code with the /clr switch, and ItJustWorks, and you can access all of the managed class library, plus all of the standard C runtime library. If you want to expose classes to the rest of the CLR, then you have to start using __gc classes, which are restricted to single-inheritance (as well as various other subtle differences that arise from them being CLR classes, rather than C++ classes). -- MikeRoome''

----
'''The Company who makes it'''

''There are many arguments against MultipleInheritance, but that's beside the point; this seems like a blatant instance of EmbraceAndExtend, making something incompatible with the rest of the world but continuing to call it by the same label. Grrr.''

You mean like the Windows GDI, Internet Explorer, their original version of Java, Csharp, .NET, ChromeFX, Fahrenheit, Direct3D, Microsoft Foundation Classes, msn & msn search, and. . .

''But then..''

I can't knock the implementation itself. Microsoft does work hard to get good tools to the developers . . . maybe a generation or two behind what they use internally, but they do realize that to get good solid lock-in, the programming masses need proper tools to increase TheNumberOfWindowsPrograms out there. I'd imagine the ManagedCeePlusPlus tools are comparable to their embedded c++ tools that (from personal experience) cross-compile "real vc/gnu c++ code" nicely. The politics of TrustedComputing, "the one true clr to rule them all", and cross-compiling issues are vast, but not really technical beyond "people like to have control of computers". In the meanwhile, it looks like Microsoft is having a party for all the language fanatics out there, AND EVERYONE IS INVITED. . . oh, and it's mandatory. -- LayneThomas

----
'''Create New legacy code with ManagedCeePlusPlus?'''

Since we cannot purchase the CeeLanguage products that MicrosoftCorporation produces before days of DotNet, is it possible to create executables from this ManagedCeePlusPlus that does not require the framework libraries to be around for execution? I would accept that this language cannot be plugged into VisualStudio 6 and expect it to run, but can the "unmanaged code" it creates be used on target legacy Windows98 computers? -- dl

Also can someone tell me how can another person managed to use my IP number to add changes to this page. It is highly unlikely another person from my domain be active on Wiki, last round of changes (revision 21) has both my stuff, and changes that I do not have any involvements. -- dl

You can't create non-DotNet code with ''Managed''CeePlusPlus, but the compiler still works perfectly well without the /clr switch (which is needed to activate the managed extensions and make it emit IL instead of x86 machine code). VisualStudio 7/7.1 are still excellent environments for writing normal win32/MFC/standard C++ projects (and I'd expect that they'll still produce native-code compilers for the foreseeable future, too - even if they want all client development to switch over to WinFs in the long run, they will still support win32, and people will still need to write low-level stuff like device drivers). The misconception that they aren't is just more fallout from the horrendously muddled and mismanaged marketing campaign that was centered around DotNet...

Mike are you saying the Un-managed x86 machine code will need to run on a PC with the DotNet framework installed? I asked about its preDotNet capabilities as I am hoping one tool to serve both worlds (DistributedInternetArchitecture type of ComComponent creation (link to DotNet via ComInterOp CCW only if required, as well as native stuff for IL based DotNet).

No. Without the /clr switch, the compiler generates normal Win32 PE binaries, which will run on any win32 system, just like the older versions (well, except the optimizer is better, and you won't run into nearly as many issues with templates/STL use/general standards compliance as you would with the VC6 compiler). 
Material on VC++ in VS6 moved to VisualStudio

Sorry Mike I am still confused. Earlier you said "You can't create non-DotNet code with ..", and last paragragh you said without /clr switch the code runs on machines without DotNetFramework. Are you saying that the ManagedCeePlusPlus software itself requires DotNet (does it require VisualStudio.Net as well?), but the software it creates can be run on a say, Win98 computer. A related question is whether there are well known library incompatibilities (causing more DLL hell on Win98 PC) if I do intend to cross develop from a DotNet machine to a Win98 machine? Thanks in advance for clarifying. -- dl
 
'''Managed'''CeePlusPlus is a set of extensions. without the /clr switch, the extensions aren't valid. Hence, when you compile without the /clr switch, you're compiling '''Standard'''CeePlusPlus to a normal PE binary. If you want to use the extensions, you'll need to compile with /clr, and you'll have a dependency on the .net runtime. If you don't, it's just like any other win32 program. As for library incompatibilities, I'm afraid I can't help you, as I've managed to avoid having to deal with win98 for the last few years... I can't imagine it's any worse than deploying on win98 usually is.

Mike while you are helping me understand this ManagedCeePlusPlus, can you confirm that ItJustWorks is a friendly wrapper over PInvoke?? Also are the changes I made to the main descriptions in this page consistent with your knowledge? -- dl

[I can field this one. If you are not interested in DotNet, then ''ignore everything that says ManagedCeePlusPlus''. ManagedC++ is essentially a different language from C++, and you can ignore is just as you would ignore C#.
There are no special library problems - you have to distribute the C/C++ runtime library, but that's nothing new although it's a new version. P/Invoke is not involved at any level. -- ChrisMellon]

The latest versions of VisualStudio happily generate .NET free C++, though you cannot (then) use any of the .NET framework libraries. You can use the ATL and MFC class libraries, both of which are effectively feature frozen. You do have to be aware that the Installer bundled with VS2003 does seem to expect target installations to have the .NET framework installed, so upgrading old project can get into trouble there. Third party installers still live happily in the Win32 world. Note also that the Windows Device Driver Kit now includes a C/C++ compiler, for all your low-level work. -- SteveLoughran

----
'''Getting started with ManagedCeePlusPlus'''

Links
* sample chapter on look and feel http://www.microsoft.com/mspress/books/sampchap/6191.asp
----
CategoryDotNet CategoryCpp CategoryProgrammingLanguage

See also: AllOnePiece