MFC Migration

[gator]

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?

[Carl Daniel [VC++ MVP]]

gator wrote:

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?

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

[Marcus Heege]

Hi Gator,

"gator" <ga***@discussi ons.microsoft.c om> wrote in message
news:21******** *************** ***********@mic rosoft.com...

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?

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

[Tom Serface]

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

"gator" <ga***@discussi ons.microsoft.c om> wrote in message
news:21******** *************** ***********@mic rosoft.com...

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?

[Arnaud Debaene]

Tom Serface wrote:

FWIW,
Microsoft is still compiling their office applications native so they
are following this same trend.

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

[Tom Serface]

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

Tom

"Arnaud Debaene" <ad******@clu b-internet.fr> wrote in message
news:u6******** ********@TK2MSF TNGP11.phx.gbl. ..

Tom Serface wrote:

FWIW,
Microsoft is still compiling their office applications native so they
are following this same trend.

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

[Michael Viking]

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

-Michael Viking

"Arnaud Debaene" <ad******@clu b-internet.fr> wrote in message
news:u6******** ********@TK2MSF TNGP11.phx.gbl. ..

Tom Serface wrote:

FWIW,
Microsoft is still compiling their office applications native so they
are following this same trend.
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

[Arnaud Debaene]

Michael Viking wrote:

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

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

Arnaud
MVP - VC

[Tom Serface]

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

"Arnaud Debaene" <ad******@clu b-internet.fr> wrote in message
news:e%******** ********@tk2msf tngp13.phx.gbl. ..

Michael Viking wrote:

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

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

Arnaud
MVP - VC

[Michael Viking]

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

"Arnaud Debaene" <ad******@clu b-internet.fr> wrote in message
news:e%******** ********@tk2msf tngp13.phx.gbl. ..

Michael Viking wrote:

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

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

Arnaud
MVP - VC