MFC to VB.NET migration

[DotNetCraze]

I am VC++ and VB developer and recently learnt VB.NET because our small company wants to migrate a medium size MFC product to .NET using either C# or VB.NET. But I cannot find any guidelines or tools to help me out in this project. As we are very small team please help me with any guidelines or useful information for this migration.We could have used managed C++ with COM wrappers/Interops but that is too much overhead for future installation and testing senarios so we want to go for 100% managed solution. Is it good to go for .NET or should we remain stuck with MFC for few years?

 

[jmcilhinney]

.NET is the way of the future as far as Microsoft is concerned. Having said that, you should only migrate to .NET if you can see some specific advantage in doing so. I don't think there's much doubt that overall .NET is easier and friendlier than MFC, but you need to balance that against the job of migrating your code base. If and when you do decide to migrate, I'd be inclined to recommend C# over VB.NET if you're existing code is in C++.

 

[kulrom]

If the existing code is in C++ then there isn't doubt that you should go for VC# instead VB.NET

Regards

 

[DotNetCraze]

Thanks guys!
I appreciate taking you time for answering my queries.
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.