It Just Works??

  • Thread starter Thread starter Denny Huber
  • Start date Start date
D

Denny Huber

Here's my dilemma:


We are going to split our monolithic MFC app into a front-end GUI and an
Engine. We will re-write the front-end GUI as a WinForms exe and call from
there into the Engine. The Engine is in C++ distributed across about 60
DLLs - say 2 million lines of code.


We want to leave the Engine code pretty much as is but callable from the GUI
front-end, so we figured on recompiling it with the /clr option and I think
that can be accomplished. From the GUI front-end, I can get to simple
classes in the Engine thru "It Just Works". The GUI front-end is compiled
with /clr:pure and can #include a header file for the simple class.

The problem is trying to talk to more complicated classes in the Engine.
We've got some header files that #include other header files and ultimately
dozens of ATL headers get included. This is OK in the Engine compilation
because we are compiling with /clr only. But when I include the same class
header in the GUI code the ATL fails to compile because the GUI is compiling
with /clr:pure. I would like to get past this if anyone has a suggestion.


Secondly, I thought one way to get around this might be to skip #including
header files in the GUI front-end (like C# does) and try to access the
Engine type metadata with:


#using <Engine.dll>


and by adding Engine.dll to the list of References. Apparently, the type
information is not accessible from the Engine unless I compile the Engine
with /clr:pure or better (but this is not an option right now). Is there a
way to force the metadata into Engine.dll in such a way that I can use the
#using statement as above?


We really want this to work in such a way that we can re-write the Engine at
a more comfortable pace. It will take a major effort to re-write the
front-end and we are committed to that, but the engine needs to stay stable
while we do the re-writing.

[Note that most of my efforts are within Visual Studio 2005 Beta because I
thought the IJW and C++ syntax would be better.]

Thanks,

Denny Huber
 
Hi Denny,
But when I include the same class
header in the GUI code the ATL fails to compile because the GUI is compiling
with /clr:pure. I would like to get past this if anyone has a suggestion.
Click to expand...

no, /clr:pure could not be comatible with the unmanaged ATL code,
Is there a
way to force the metadata into Engine.dll in such a way that I can use the
#using statement as above?
Click to expand...

It appears no such method to generate the metadata of the unmaged code, do
you have checked the following MSDN doc, it suggests to create a managed
wrapper class for your native MFC class:
Walkthrough: Porting an Existing Native C++ Application to Interoperate
with .NET Framework Components
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample/ht
ml/vcwlkportingnativetointeroperatewithnet.asp


And the VS.NET 2005 has a big change from VS.NET 2003, for the it is still
under testing scenario(Beta 2), we suggest you post this problem in our
Whidbey Technology Preview newsgroup
http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slcid=us


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Hi Denny,

Is my reply useful to your problem?
If you have any more concerns on it, please feel free to post here.


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
I have found a workaround for my above problem.

I wrap the iterator from my native project into a "__nogc class".

For any unknown reason this resolved the problem.

Even though I can live with that, I would like to know whats wrong, to
avoid these kind of things in the future.

thanks

Ingo

*-----------------------*
Posted at:
www.GroupSrv.com
*-----------------------*
 
Back
Top