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
