MFC Migration

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am thinking of migrating our MFC application to .NET using C++/CLI. My
question is does a migration from MFC applications and ATL to WinForms make
sense, given that XAML is likely to be the approach of the future?
 
gator said:
I am thinking of migrating our MFC application to .NET using C++/CLI.
My question is does a migration from MFC applications and ATL to
WinForms make sense, given that XAML is likely to be the approach of
the future?
Click to expand...

IMO, no. There's no need to abandon your existing C++ code base.

Port your MFC/ATL application to VC++ 2005 today. You can add new features
(views, forms, etc) using Winforms today and using Avalon when the time
comes.

-cd
 
Hi Gator,

gator said:
I am thinking of migrating our MFC application to .NET using C++/CLI. My
question is does a migration from MFC applications and ATL to WinForms
make
sense, given that XAML is likely to be the approach of the future?
Click to expand...

IMO migrating our MFC application to .NET using C++/CLI is the only option.
Being stuck in the native world is not an option given that we currently
have version 2 of .NET and .NET is *the* accepted technology for user mode
development on MS platforms. Rewriting your code from scratch is not an
option given that WPF is not released and WinForms is not the API of the
future.

Moving to .NET using C++/CLI and IJW (nowadays called "Interop
Technologies"), allows you to
* keep your UI as it is instead of implementing an intemediate solution
* refactor and extend your application towards .NET step by step
* use all features of the base class library - not only winforms
* integrate WinForms controls in MFC dialogs and views
* integrate Avalon (WPF) controls in MFC dialogs and views
 
I haven't done anything with the 2005 version of WinForms yet, but the
version in 2003 was not suited for a larger desktop application in my
opinion. I agree with Carl and I'd wait until there is more info. I do
support the paradigm of managed code, in theory, but for now I need my
desktop applications to run as quickly as possible and since they are large
to compile as small as possible. I can see lots of things to use .NET for,
but so far this is not one of them. FWIW, Microsoft is still compiling
their office applications native so they are following this same trend. I
don't know if they use MFC for Office any more or not, but that's a whole
different question :o)

Tom
 
Tom said:
FWIW,
Microsoft is still compiling their office applications native so they
are following this same trend.
Click to expand...

Oh no, please! Don't start again the question "Why hasn't Microsoft
converted the whole multi-million lines code base of Office to .NET" !

Of course they haven't ported it! What would be the point? What would be the
added-value, both for Microsoft and for the customers? It would be several
man-years of work without adding any features, without correcting any bug
(worse, it will most probably add new bugs).
Not porting Office doesn't assume anything about .NET qualities (or lack
thereof) for GUI apps.

Arnaud
MVP - VC
 
Good point. Of course the same applies to others with working applications
in MFC. That's all I was saying.

Tom
 
Like Tom correctly points out: MS expects everybody else to port. Don't
they?

-Michael Viking
 
Michael said:
Like Tom correctly points out: MS expects everybody else to port.
Don't they?
Click to expand...

No, I don't believe so.. What have you seen, read or heard that make you
think so?

Arnaud
MVP - VC
 
Actually, to be fair, I've never heard any one at Microsoft tell me they
expect me to port and I wasn't trying to insinuate that. There is a big
push towards managed code, rightfully so, but everyone I've talked to about
my applications tells me that porting them to managed code should be a
gradual process since they already work. As .NET continues to improve it
becomes more compelling as well.

So, my take, is: it's a good idea to start working towards living in a
managed world, but I wouldn't drop everything and feel I'm not "up to date"
if I'm still compiling natively. I think the smart thing to do is consider
the application, the legacy code, and what you intend to do with it. For
example, I hate using Xerces to parse XML. The .NET XML parser, in my
tests, works great. I plan to really quickly port my XML parsing to managed
code even though other parts of my application are still compiled native.
I'm really glad C++ 2005 allows me to do that.

Tom
 
Well, I may be speaking out of turn and it's pretty hard to search for
articles of this nature to determine one way of the other. It's just the
general feeling I've developed over the years of reading these newsgroups.

-Michael Viking
 
Hi Michael,

Microsoft has made no secret that trustworthy and secure computing is a huge
inititive of theirs (and should be ours). One of the components of that is
the managed code paradigm. However, like I said, they haven't really been
too pushy about it. Case in point, VS 2005 is even better at compiling
native code than was 2003. As time goes on and as .NET continues to improve
I think we'll all see the benefit of moving that direction. As we continue
down that path, we'll just keep getting our work done. :o)

Tom
 
Read the whole thread of MFC/VC++ porting onto .Net and many many
companies are now helping clients port teh applications including us -
S7 [s7solutions.com] and is something almost every one is seeking
nowadays.

Regards
Manju

*** CUSTOMER comes FIRST, come what may ********

Manjunath M
S7 Software Solutions Pvt. Ltd.
#83 Railway Parallel Road, Kumara Park West
Bangalore - 560020, India
Telephone: +91-80-51526777
Fax: +91-80-2334135

2936 173rd CT NE
Redmond, WA 98052, USA
Telephone: (425) 867 1457
Fax: (425) 883 2597
Toll Free: 1-888-224-6174

Yahoo messenger ID: s7softwaresolutions
MSN messenger ID: (e-mail address removed)
Skype ID: s7softwaresolutions

http://www.s7solutions.com

"Redefining cross-platform porting & migration"

************************************************
 
Rewriting your code from scratch is not an option given that WPF is not
released and WinForms is not the API of the future.
Click to expand...

Why are Winforms not the API of the future? Is everything going to be WPF?

Thanks,
David
 
gator said:
*I am thinking of migrating our MFC application to .NET using
C++/CLI. My
question is does a migration from MFC applications and ATL to
WinForms make
sense, given that XAML is likely to be the approach of the future? *
Click to expand...

XAML will be in mass use only by 2007 and I would suggest you to
migrate to Windows form first because that will help you for future
migration to XAML. I just finished my MFC application migration to C#
and it was not as difficult as I thought because writing code in .NET
is compact and really faster. I used RC Converter (
http://www.dudelabs.com ) to convert UI from MFC to Windows
Form. RC Converter supports VB.NET and C++/CLI too so for your C++/CLI
project it should not be a problem.After UI I wrote all business logic
code from scratch and it did not take that long. I would suggest you to
migrate to windows form first.
 
Back
Top