Is Visual C++ memory managed by the Dot Net framework

Question

Recently, I've been dealing with an error with accessing MAPI via the .NET framework (as described in this article). I am now left with a series of memory access violation errors.

To get past the issues, I have been trying to use this 3rd party component, which has a Visual C++ core. Unfortunately - we are still having the same errors.

I've personally never used Visual C++, but my question is: if the C++ library is compiled using Visual Studio 2005, using Visual C++ - does the memory of the project become managed by the .NET framework, as well, which would therefore make it subject to the same issues as the .NET libraries we're using? Or am I barking up the wrong tree?

Answer 1

I'm not entirely sure what you're asking, but i'll give it a shot.

Visual C++ is a pure C/C++ compiler so has none of .NET's memory management, nor any of its runtime -- You have to manually call new and delete.

.NET also provides C++/CLI, which is a slightly modified version of C++ that targets the .NET runtime, and is GC aware -- eg. its memory is managed by the .NET runtime.

Without more details about your bug I can't really make any suggestions, beyond suggesting that you make sure you use the appropriate GC guards, and the provide finalizers in any place they are needed.

Answer 2

The two previous answers have mentioned "Managed C++", this is an old bolt-on that they did to allow you to use managed C++ in a .NET environment. It wasn't a first class citizen - unlike C++/CLI (link text. But to answer your original question, no, Visual C++ is not managed by the .NET runtime. Managed C++ & C++/CLI are.

Answer 3

Unless you are using Managed C++ (which it doesn't sound like you are) then no, the memory is not managed by the CLR.

The recommended method of talking to Exchange in .Net is via WebDAV.