port a MFC application to .NET

[Tony Johansson]

Hello!

We have a big and rather complex MFC dll that we intent to port to .NET.
If we intent to port the code to a managed C++.dll will this be nearly as
much as rewriting
everything to C#.

//Tony

[xcal]

Re: port a MFC application to .NET

I believe for things like this VC++ 6.0 permits to you to build your COM components.

Carlos

"Tony Johansson" <t.johansson@lo gica.comwrote in message
news:e5kEFApOJH A.1576@TK2MSFTN GP06.phx.gbl...

Hello!
>
We have a big and rather complex MFC dll that we intent to port to .NET.
If we intent to port the code to a managed C++.dll will this be nearly as
much as rewriting
everything to C#.
>
//Tony
>

[Peter Duniho]

Re: port a MFC application to .NET

On Thu, 30 Oct 2008 06:04:16 -0700, Tony Johansson
<t.johansson@lo gica.comwrote:

We have a big and rather complex MFC dll that we intent to port to .NET.
If we intent to port the code to a managed C++.dll will this be nearly
as much as rewriting
everything to C#.

That depends on how you port it. But, if you leave most of the code alone
and just write a managed code wrapper for it, I think it would probably be
much less work than rewriting everything from scratch in C#. I think you
should be able to write a managed C++ wrapper in its own module, so that
you don't even have to touch the MFC DLL itself.

For that matter, you might find that writing the wrapper in C# using
p/invoke works well too. Personally, I've found it difficult to find
really clear, comprehensive documentation on how to use p/invoke but it's
been awhile since I've tried. Maybe the doc situation is better now.

Making the wrapper in C++ will require a little extra coding, but you'll
have more direct control over how data is marshaled. Conversely, using
p/invoke might make certain conversions harder to do, but most of the
implementation should simply be declarations and wrappers, which could
make the coding go faster (depending on how long it takes to get up to
speed with p/invoke).

All that said, if your intent is to actually _rewrite_ the DLL in managed
C++, I don't see how that'd be significantly simpler than doing the same
rewrite in C#. Managed C++ is a lot more like C# than it is like MFC.
Most of the effort will be in translating the MFC stuff to .NET, and that
work will be the same in managed C++ as in C#. If you're looking to
actually rewrite the DLL, I'd say pick your language based on your
intended future use...the actual porting isn't likely to be affected much
either way.

Pete