Herby wrote:
Thanks Willy.
My specific problem is I want to serialize a parallel .NET object graph
derived from my current MFC objects.
This will then be used in a new .NET application which compiles with
\clr safe
I want to keep the original source application native. Only selectively
using managed code where absolutely necessary.
E.g.
compile UnManagedClass.cpp as \clr
#pragma unmanaged
// All methods here compile to pure native ... As they always were
// Each class participating in the conversion to .NET will implement
the following new method(interface)
// which must be managed for reasons already discussed.
#pragma managed
UnManagedClass::Convert2DotNet( DotNetConversionContext& context )
{
ManagedClass^ pMC = gcnew ManagedClass;
/// set properties on pMc from 'this' native data members
context.Add( pMC );
}
Its only this method i want compiled as managed everything else stays
the same.
So, i do not require mixed type classes as i have no need to maintain
state.
Hi,
What you said in this thread is correct. #pragma managed has no meaning
in a file not compiled with the /clr switch. The compiler needs to know
ahead of time (before it starts processing the file) that it will
encounter managed blocks since tha implies it needs to generate metadata
. That happens even in #pragma unmanaged blocks.
E.g. in your example the compiler needs metadata (even just the opaque
valuetype definitions it generates for native classes) for class
UnManagedClass in order to generate the method correctly in managed code.
So there is a clear difference between a file that is not compiled /clr
and one that is compiled /clr but has #pragma unmanaged as its first
line: the first does not generate any metadata, the second does.
Ronald Laeremans
Visdual C++ team