MFC to C# or VB.NET - How????

Please help me with some instructions or guidelines for migrating my medium size MFC application to .NET using either C# or VB.NET. I can not find any tool or help at all and now I am thinking not to do anything and just see my app die when MFC support is taken off by Microsoft.
/clr switch and com wrappers are not as clean as managed code where I need not to worry about including those mfc dlls in install. Maintenance gonna be a problem too. Because I am the only one programmer in a small company I have to do it somehow and it's driving me nuts. Any help is appreciated.

Probably easiest to just start over using C#.

I agree. The move to managed code isn't something that you can just flick a switch with.

(Yes I know you can flick the "managed" switch in VC++.NET but that's not what I meant).

You need to rework the requirements of your application using the functionality which is available in .NET. E.g. events and delegates, for which in C++ you have to implement an observer pattern.

You have to consider your current environment, and whether it's worthwhile.

But you really are looking at a rewrite unless you've used modularised programming techniques (e.g. using COM dlls).

Managed programming isn't necessarily for every application.

However, like with the move between assembler and C, or even C and C++ if the world moves on and your application doesn't, it'll soon be left behind.

We are taking part as developers in a programming revolution.

Bosses usually don't recognise that technology moves on and sometimes the code needs to be thrown away in favour of newer technologies.

I think most predictions are that in the next 10-20 years managed code will supercede C++ development and if you don't upgrade your systems, then you've got problems.

That's the premise which I'm personally working on. And with the inevitable release of Windows Vista I doubt that I'm wrong in assuming this.

Darwen.

Thanks guys!
I appreciate taking you time for answering my queries. Thanks Darwen for your insight!
We did lots of research to find the solution and worked through weekend to test the prototype for migration and I am happy to tell you that we are almost done with finalizing the strategy of our migration even though it might be premature.
you can call our app medium/huge(may be) because of many user input screens used by customer care dept. in health industry for all kinds of queries. Mostly it saves the data directly in database without complex validation and business logic involved.
We used DudeLabs "RC Converter" [ http://www.dudelabs.com/Products.aspx ] to convert all our MFC User Interface into windows form resources which saved many days of work and we could do the prototype test so soon.
We are trying to use Visual Studio 2005 smart client concept because of distributed data sources but we have not yet decided on synchronization of data in case of disconnected datasource.
Because our UI is done we are far ahead of our estimated schedule, we hope we will fix our technical issues soon.
One important thing to share with people struggling with datagrid in VS 2003 -- DataGridView in 2005 is really great as compared to DataGrid in Visual Studio.NET 2003 so if you can switch to 2005 please go ahead because you will have better experience and more fun.
I am C# / C++ programmer but we are using C# and VB.NET both in our development strategy because our old application used MFC mostly for UI purpose and it is easy to translate UI logic in C# as well as in VB.NET.
But be careful if your product uses MFC heavily with complex MFC concepts because in that case prefer C# as others suggested too.
Once again thanks for your suggestions and will bother you once again if I hit roadblocks in my migration path.

Thanks for sharing the info Dotnetcraze!
Could you please tell me about the experience with smart client using disconnected data source because we had major issues with synchronization of databases and had many record conflicts once the user was online with database specially update operations.

Sorry for replying late Paul !
But we were in process to make decision about disconnected distributed data source issues in smart clients and unfortunately we decided not to use disconnected data source model. Our software cannot afford merge issues at all.
Even our customers prefer to wait for their database to be online and then make updates rather hit override issues. We had same issues as you mentioned and I think you can fix it with correct database design. But if you do not wish to change database design then please be careful with disconnected datasource. It is good to use this concept but I will suggest to use it only if you really need to apply this in your product and you will get major benefits. Hope you will get some help if you plan to go ahead! I will suggest you to ask your question in a new thread mentioning your problem and I am sure you should get an expert answer from somebody who is good at smart client concepts.

We have also dropped the disconnected datasource idea. Thanks anyways!