|
I believe it! Companies typically have a large investment of time and money in code and development effort. Although such a decision is a "no-brainer" for us geeks, it represents a risk and a commitment of time and money to convert a code base. So there are some serious business considerations before converting your application to .NET.
From a technical perspective, let me ask why you want to convert the application? There's no technical reason why you MUST convert the application, since COM based applications will be supported for a long time to come. Do you have compelling reasons that will save the company or its users time or money? Do you need the caching abilities of ASP.NET Web Forms? Will the new deployment abilities of Win Forms reduce the amount of DLL versioning problems you are currently experiencing? What do you hope to achieve by doing this? I know the answer to that question within my organization, but I can't answer that for your organization.
The Visual Basic Upgrade Wizard in Visual Studio.NET takes most of the hard work out of converting an application from Visual Basic 6 to VB.NET. (To use the wizard, you simply open the project in Visual Studio.NET just like you would open any other project. Visual Studio.NET can sense that you are opening a Visual Basic 6 project and will pop-up a Wizard window to determine how you want to handle this.) It even gives you a report on what it can and can't do, with full explanations and To Do items.
Although I'm not an "expert" in the are of migration from VB6 to .NET, I too have heard that there will be issues. From what I understand, if your application was coded in a fairly straightforward manner and you made reasonable design and coding choices, you'll experience a higher degree of success. I think the applications developed by people who were very new to Visual Basic or individuals who thought they could optimize the application by taking some non-standard development approach will experience the greatest amount of grief. Also, if you relied heavily on third party controls, components or DLL's, then you may experience more issues than an application that did not.
There's one quick way to find out what your impact is... run it through the Wizard. This will not affect your current source code. After studying the result of the migration (via the _UpgradeReport.htm that is generated and accessible in the Solution Explorer), you'll have a pretty good idea of the issues, and will probably be able to estimate the amount of effort needed to get the code into working condition.
However, (and this will probably be a VERY unpopular view) I would not recommend using the Upgrade Wizard at all for certain applications (like COM+ components in a high traffic web environment). Instead, I would recommend a complete re-write. The reason is because I fear the impact in large volume environments of the impact of interop between COM+ and .NET for component calls. Again, after you run the wizard, you can evaluate what areas of the application could cause potential for extra processing due to interop.
|
