Windows, MFC, .NET, C++ ???

It's been a while since I've posted on the boards, or have programmed for that matter. But I'm getting back into it.

I've mostly worked with C++, some C, but what I remember most is C++. I have not yet worked with MFC or Windows programming.

I have this program that was written with MFC in C++. I'd like to know what exactly I'm looking at. I tried to find some tutorials through google, but I'm still somewhat confused.

I'm also looking at using .NET. I have yet to program with .NET.

So I'm looking at mixing the MFC with .NET, or getting it over to .NET.

The program was written with VS 5, and I was given a copy of that to use. I can get a hold of VS .NET 2003 as my school offers licenses to each engineering student.

I'm looking at keeping it C++.

So my questions are:

Is there any recommended books or online references/tutorials on MFC and .NET?

Anything that would make the MFC to .NET transition easier?

hmm, and any tips or recommendations in general. I'm sure I'll come up with more questions.

Thanks.

Mixing .NET and MFC is bad.
Why porting an already working MFC code to .NET?

Quote:

---

Originally Posted by siavoshkc

Mixing .NET and MFC is bad.
Why porting an already working MFC code to .NET?

---

Client wants it.

Basically, trying to port to .NET yet still be able to access an unmanaged DLL.

Is this client end user or not?
[edit]
I think it shouldn't be. They are wasting their money.

I don't know that I agree. The port is possible and reasonable. MFC is outdated and it should be moved. What's a more reasonable alternative than porting to .NET?

In fact, all you need to do is add the /clr flag to your MFC project makes it a .NET capable app.

Take one dialog at a time. Over time, the MFC will be gone.

If it's portability you're really worried about, you should use Java then. As far as .NET usage goes, Microsoft still writes its own applications in Vista (Notepad, Wordpad, Office, etc) in native code using MFC and the API.

MFC is fine for next 5 years.

Quote:

---

Originally Posted by alpha

yet still be able to access an unmanaged DLL

---

You may be looking at writing wrappers for these unmanaged DLLs, if there isn't already a managed .NET version available. Or do you mean system/MS DLLs? (In which case a .NET version or counterpart is probably already available)

The unmanaged DLL is part of a driver package. It is third party and needs to be incorporated into the software.

Anyways, any recommended reading material?