mfc or dotnet?

[Rainer Queck]

Hello NG,

I am in the situation, that I have to evaluate on how a existing software
system is to be redesigned.

The current system is developed with C++/MFC over a period of several
years.
It is causing unacceptaple problems and I currently can't say (it's not my
system) whether this is because of poor designe or poor programing. What I
have seen of it lets me consider a complete redesign.

The question I now have to answer is : shell this redesign be done with
C++/MFC or would it make more sense to do it with .NET and C#.

For me, as I am using C# and .NET since a couple of years, the answer seems
to be clearly .NET but...
There also might be some good and reusable code fragment in the existing
project, and the team currently working on the project in question would
prefere C++/MFC.

Looking into the future a couple of years, what would be the right decision
in this case?
Will MFC presumably be supported as long as .NET?
Will new technologies/methodology - I am thinking of LINQ,WCF, ..- be added
and cultivated in MFC?

Thanks for any comment, link or thought on this question.

Regards
Rainer Queck

 

[Jason Newell]

This is like asking a Java or .NET question in a Java forum. Don't you
think that you should have cross posted to the microsoft.public.vc.mfc
forum to give those fellas a chance. Many of the MFC guys have .NET
experience and can give you unbiased answers.

Jason Newell
www.jasonnewell.net

 

[Rainer Queck]

Hi Jason,

This is like asking a Java or .NET question in a Java forum. Don't you
think that you should have cross posted to the microsoft.public.vc.mfc
forum to give those fellas a chance. Many of the MFC guys have .NET
experience and can give you unbiased answers.

Basically I think you are right.
But I am hoping for answers from developers who already made the step form
MFC -> .NET and there by knowing both sides.
Since I doubt that there is any body on this world how made the step from
..NET -> MFC (which I then would expect in the microsoft.public.vc.mfc) I
don't expect too much from doing so.

Regards
Rainer Queck

 

[Cor Ligthert[MVP]]

Jason,

Almost my idea too, moreover the question is about mfc or dotnet.

Not about C# or C++.

With C++ you can cover both, so the language.cb newsgroup looks to me the
right place to ask this, not even the mfc newsgroup.

Not here, because here it is like asking an Englisman what is a beter
language to speak, English or French.

jmo

Cor

 

[Asses for the Masses]

Hi Rainier,

I think you have to consider a couple of things.

1. Cost of Code Reuse vs. Cost of Code Rewrite -- how much of the previous
code is salvageable and will fit in the new architecture (regardless of
whether the new architecture is based on MFC or .NET)?

2. Performance -- is the application of the type that it will benefit from
being implemented in unmanaged code?

3. Architecture -- can you leverage .NET to implement design patterns to
simplify code design?

I know this isn't the answer, but you can use the above to help you think
about your decision. I suspect you won't really find an answer here.

Regards,

Umar.

 

[Pavel Minaev]

Hello NG,

I am in the situation, that I have to evaluate on how a existing software
system is to be redesigned.

The current system is developed with C++/MFC over a period of  several
years.
It is causing unacceptaple problems and I currently can't say (it's not my
system) whether this is because of poor designe or poor programing. What I
have seen of it lets me consider a complete redesign.

The question I now have to answer is : shell this redesign be done with
C++/MFC or would it make more sense to do it with .NET and C#.

For me, as I am using C# and .NET since a couple of years, the answer seems
to be clearly .NET but...
There also might be some good and reusable code fragment in the existing
project, and the team currently working on the project in question would
prefere C++/MFC.

If the reusable code fragments include UI logic, then MFC might make
sense, depending on how much there is of that code. If it's all non-UI
related, then go for C++/CLI and .NET/WinForms - that way you have a
higher-level and more convenient UI framework, but can reuse all the
old code (and you can keep using the non-UI MFC classes such as
CString in the backend too, at least until you have time for a
cleanup).

Will MFC presumably be supported as long as .NET?

It's hard to say. .NET will certainly be supported for years to come
now. MFC was considered abandoned by many not long ago, but Microsoft
has renewed the push for native code frameworks and tools recently,
and MFC in particular had seen a few pretty big updates. I think it
will stick around, too.

Will new technologies/methodology -  I am thinking of LINQ,WCF, ..- be added
and cultivated in MFC?

I don't think you will see much new "tech" in MFC itself, but why
would you even care if it's there or not? LINQ is not there for C++/
CLI, it won't be there in VC10, and I doubt it will ever happen
anyway; but VC10 adds C++0x lambdas, which, combined with STL,
effectively do everything that LINQ to Objects does. LINQ to SQL and
similar technologies - forget about it, that's not what C++ is about.
In any case, why would you need all those things "in MFC"? One good
thing about C++ is that there are existing libraries for pretty much
everything, and you can mix and match as you see fit. MFC is not the
be-all end-all, even for pure C++/Win32 development.

As for WCF - for one thing, you can use it today together with MFC if
you use C++/CLI and compile for .NET and not native. On the other
hand, Win7/Win2008R2 comes with a native C++ API to write and use web
services - not sure if it'll be provided for older OSes, though. Then,
of course, there are many free third-party offerings, too.

 

[Larry Smith]

Hello NG,

I am in the situation, that I have to evaluate on how a existing software
system is to be redesigned.

The current system is developed with C++/MFC over a period of several
years.
It is causing unacceptaple problems and I currently can't say (it's not my
system) whether this is because of poor designe or poor programing. What I
have seen of it lets me consider a complete redesign.

The question I now have to answer is : shell this redesign be done with
C++/MFC or would it make more sense to do it with .NET and C#.

For me, as I am using C# and .NET since a couple of years, the answer
seems to be clearly .NET but...
There also might be some good and reusable code fragment in the existing
project, and the team currently working on the project in question would
prefere C++/MFC.

Looking into the future a couple of years, what would be the right
decision in this case?
Will MFC presumably be supported as long as .NET?
Will new technologies/methodology - I am thinking of LINQ,WCF, ..- be
added and cultivated in MFC?

Thanks for any comment, link or thought on this question.

Nobody can possibly answer your question without evaluating your situation.
If you're worried that MFC is going to disappear anytime soon however, it's
not. In the general case however, C++ will only become more difficult to
support as the years go on. It will also become more difficult to find
skilled C++ developers which have always been in short supply anyway (and
they will only get more scarce and more expensive). If your shop is typical,
then the problems you mentioned likely exist for that very reason
(substandard developers). Therefore, if your project does in fact lend
itself to .NET and you can absorb the cost of a re-write (in C#), then I
would seriously consider it. Most developers can't handle C++ so it's better
to trust them with a more forgiving language. A re-write can be a daunting
task but it's short-term pain for long-term. Ultimately however, only you
and your colleagues really know whether it's an avenue you can afford to
travel down (and many of your colleagues are likely responsible for the
current mess so I'd be extremely cautious about trusting them - this is the
unfortunate reality).

 

[Doug Forster]

Actually even the OPs question is biased for you can have both with MC++

Cheers
Doug Forster

 

[harborsparrow]

I'm going to assume that the reason existing developers want to stick
with C++/MFC is that it's what they already are comfortable with (not
the best of reasons, but very common).

Normally, .NET would be my recommendation; it is cross-operating
system and performs well, and further it is type-safe so you are far
less likely to get crashes due to mismanaged memory and pointers and
the like.

However, is there some functionality needed in the app that is not
available via the .NET libraries? That *could* be a reason not to
switch, though it is also possible to call into the Windows API
from .NET. Another reason might be performance, but only if handling
large amounts of multimedia such as video or sound.

Otherwise, down with conservative failure of people to upgrade their
skills, and up with a newer, more robust platform that performs
superbly and is type-safe.

 

[Colbert Zhou [MSFT]]

First thanks for everyone's discussion here. Without your proactive posting
and warmhearted help, the Microsoft newsgroup cannot achieve today's
success.

And Rainer, I agree with the above comments that there may be not an answer
without evaluating your situation, especially related to what problems is
unacceptable currently. So we are just trying to give some suggestions.

From my perspective, I consider it as a good idea that moving to the .NET
platform because more and more people are using .NET to develop their
applications. And you also have many years' experience on .NET as you said.
Since .NET is the trend in future, just in my opinion, I think Microsoft
will focus its most investment in the .NET. Actually, most of the new
technologies are based on .NET platform, for example, Microsoft's cloud
computing product, Azure. So I am pretty positive .NET will have a longer
life cycle than MFC. And of course, it will have a better integration with
the new technologies as you mentioned, LINQ, WCF, Windows Azure and so on.

And if we do not want to absolutely abandon the C++/MFC codes in the first
version of our new C# application. We can still use P/Invoke to reuse some
of the logical codes in original C++ dll. So that part does not need a new
implementation.

Does this make sense to you?

Wish you have a good day!


Best regards,
Colbert Zhou (colbertz @online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[usenet]

Hello NG,

I am in the situation, that I have to evaluate on how a existing software
system is to be redesigned.

The current system is developed with C++/MFC over a period of  several
years.
It is causing unacceptaple problems and I currently can't say (it's not my
system) whether this is because of poor designe or poor programing. What I
have seen of it lets me consider a complete redesign.

The question I now have to answer is : shell this redesign be done with
C++/MFC or would it make more sense to do it with .NET and C#.

For me, as I am using C# and .NET since a couple of years, the answer seems
to be clearly .NET but...
There also might be some good and reusable code fragment in the existing
project, and the team currently working on the project in question would
prefere C++/MFC.

Looking into the future a couple of years, what would be the right decision
in this case?
Will MFC presumably be supported as long as .NET?
Will new technologies/methodology -  I am thinking of LINQ,WCF, ..- be added
and cultivated in MFC?

Thanks for any comment, link or thought on this question.

Regards
Rainer Queck

Short Answer: C#.NET 3.5

Longer Answer: Unless it's a game, or computationally intensive, or
will run on older-systems, then using .NET 3.5 is recommended.

 

[Arne Vajhøj]

This is like asking a Java or .NET question in a Java forum.
Yep.

Don't you
think that you should have cross posted to the microsoft.public.vc.mfc
forum to give those fellas a chance. Many of the MFC guys have .NET
experience and can give you unbiased answers.

But there are probably also some that despise .NET !

Arne

 

[Arne Vajhøj]

I am in the situation, that I have to evaluate on how a existing software
system is to be redesigned.

The current system is developed with C++/MFC over a period of several
years.
It is causing unacceptaple problems and I currently can't say (it's not my
system) whether this is because of poor designe or poor programing. What I
have seen of it lets me consider a complete redesign.

The question I now have to answer is : shell this redesign be done with
C++/MFC or would it make more sense to do it with .NET and C#.

For me, as I am using C# and .NET since a couple of years, the answer seems
to be clearly .NET but...
There also might be some good and reusable code fragment in the existing
project, and the team currently working on the project in question would
prefere C++/MFC.

Looking into the future a couple of years, what would be the right decision
in this case?
Will MFC presumably be supported as long as .NET?
Will new technologies/methodology - I am thinking of LINQ,WCF, ..- be added
and cultivated in MFC?

There are lots of MFC apps working very well, so the problem must
be in your code.

If you start from scratch, then C# and .NET seems obvious. I can not
right away think of any reason to pick C++ and MFC for a new app
today.

But I would think it was worth getting an external MFC expert
to look at the app and evaluate whether it could be fixed
cheaper than rewriting from scratch.

MFC will be supported for a long long time, because there are so many
important apps written using it.

But it will be more and more maintenance only no new apps.

Arne

 

[Arne Vajhøj]

Normally, .NET would be my recommendation; it is cross-operating
system

MS .NET and Mono compatibility for GUI has not been convincing.

GTK# would probably be the best pick for portability !

and performs well,
Yes.

and further it is type-safe so you are far
less likely to get crashes due to mismanaged memory and pointers and
the like.

Yes.

Arne

 

[not_a_commie]

Looking into the future a couple of years, what would be the right decision

in this case?

Not MFC.

Will MFC presumably be supported as long as .NET?

Supported? Has it even been acknowledged since 1997? It's 12 years out
of date, not to mention it's a PITA compared to .NET coding and
debugging.

Will new technologies/methodology -  I am thinking of LINQ,WCF, ..- be added
and cultivated in MFC?

Not a chance. If this is a GUI app I think you should be using WPF or
GTK# for any serious application rework. If you need existing .Net UI
components I'd consider using WinForms otherwise I'd go with something
more modern. The only way I'd consider using C++ is if you need to use
some existing C++ libraries that are hard to port like LAPACK and BLAS.

 

[Arne Vajhøj]

Supported? Has it even been acknowledged since 1997? It's 12 years out
of date,

It was updated in Visual C++ 2008 Feature Pack release April 2008.

not to mention it's a PITA compared to .NET coding and
debugging.

If your opinion about using MFC is as well founded as you opinion about
when it was last updated then ...

Arne

 

[Ajay Kalra]

Not MFC.

Why? It has its place even now.

Will MFC presumably be supported as long as .NET?

Supported? Has it even been acknowledged since 1997? It's 12 years out
of date, not to mention it's a PITA compared to .NET coding and
debugging.

MFC is fully supported today and has been since 1997. I cant see a scenario
where it wont be supported in future. Support doesnt mean enhancements.

 

[Ajay Kalra]

It was updated in Visual C++ 2008 Feature Pack release April 2008.

Yes, but it was really a third party toolset that was added to it.

 

[Arne Vajhøj]

Yes, but it was really a third party toolset that was added to it.

That may be.

(I am not that familiar with what is going on in MFC land)

But it is still an indication of that new functionality was
delivered.

If MS paid MS employees to write the code or paid an external
company for the code is another question.

Arne

 

[SbjCat]

I know that I support the advancement of MFC....

http://www.codeproject.com/KB/architecture/MvcIntro.aspx