How dependant is the converted code from support (helper) classes?
The migration philosophy behind the Visual Basic Upgrade Companion is to produce native .NET code with no dependency on the legacy platform or any third-party runtime, so that you can effectively take control of the evolutionary path of the migrated applications without any restrictions. To ensure this, the Visual Basic Upgrade Companion’s artificial intelligence-based engine generates VB.NET or C# code with the direct support of the .NET framework, but whenever this is absolutely not possible, due to API differences or code readability and maintenance, the tool makes use of support classes. However, you always have access to the library’s source code so that there’s no dependency on ArtinSoft. Other VB to .NET migration tools rely heavily on extensive .dll libraries containing lots and lots of functions and classes that emulates Visual Basic 6 behavior in the .NET platform. For example, they generate one class per each VB6 control, so that every single control used in the migrated app