The short answer is that VB6 and VB.NET (and consequently C#) are separate language but related languages. There are many subtle (Integer being Int32 instead of Int16) and gross differences (graphics, form, and printing engines) between the two platforms. You need to treat this as if you are converting to a completely different platform.
At GreatMigrations, we do this by hand -- we use our hands to develop a VB6/COM compiler. The compiler reads a VBP (or group of related VBPs) and referenced COM libraries and constructs a "semantic model". This model is an extremely detailed set of symbol tables and opcode streams that fully and accurately describe all information structures defined and operations performed by the source system.
The tool then applies a series of algorithms that modify and restructure the model to make it more compatible with .NET and optionally applies custom transformations; for example to replace COM components with .NET classes. The transformation rules are designed by people and created "by hand" to meet their unique requirements.
Finally, the model is "executed" but instead of allocating the data model and executing the operations, we author the file structures, data model, and operations in the notation of the target platform. We can author both VB.NET and C# using this approach. We also use this process to migrate ASP sites to ASPX, (we also have a multi-dialect FORTRAN-to-C product)
The approach does not produce production ready software on the first try, but it can be improved and made to produce "better" software by modifying the configuration of the tool and re-running the translation process. The advantage of our tool is its repeatability, speed, and flexibility which facilitates an agile tool-assisted-rewrite methodology. IMO, migration teams that leverage our approach will benefit from allocating a lot more resources to evaluating alternatives for redesign, and development process improvements rather than to re-gathering functional requirements, hand coding, and testing. They will ultimately enjoy a more maintainable system and a much more faithful reproduction of the original application functionality after the migration as well as greater control and visibility during the migration.
A trial edition of our tool is available here gmStudio Trail Request Download. It will allow you to experiment with ASP/VB codes up to 10K LOC and runs for up to 30 sessions.
Microsoft and ArtinSoft have partnered to offer a free VBUC license to you. The discount code below can be used to purchase a license that will allow you to migrate an application of up to 10,000 lines of VB6 code to VB.NET or C# for free. It can also be applied when purchasing a larger license.
It's not perfect, resulting code still requires lots of manual fixes until it even compiles but still this tool is worth giving a shot.
The short answer is that VB6 and VB.NET (and consequently C#) are separate language but related languages. There are many subtle (Integer being Int32 instead of Int16) and gross differences (graphics, form, and printing engines) between the two platforms. You need to treat this as if you are converting to a completely different platform.
The issues is explored more fully here
How to Switch a Large App from VB6 to VB.NET
At GreatMigrations, we do this by hand -- we use our hands to develop a VB6/COM compiler. The compiler reads a VBP (or group of related VBPs) and referenced COM libraries and constructs a "semantic model". This model is an extremely detailed set of symbol tables and opcode streams that fully and accurately describe all information structures defined and operations performed by the source system.
The tool then applies a series of algorithms that modify and restructure the model to make it more compatible with .NET and optionally applies custom transformations; for example to replace COM components with .NET classes. The transformation rules are designed by people and created "by hand" to meet their unique requirements.
Finally, the model is "executed" but instead of allocating the data model and executing the operations, we author the file structures, data model, and operations in the notation of the target platform. We can author both VB.NET and C# using this approach. We also use this process to migrate ASP sites to ASPX, (we also have a multi-dialect FORTRAN-to-C product)
The approach does not produce production ready software on the first try, but it can be improved and made to produce "better" software by modifying the configuration of the tool and re-running the translation process. The advantage of our tool is its repeatability, speed, and flexibility which facilitates an agile tool-assisted-rewrite methodology. IMO, migration teams that leverage our approach will benefit from allocating a lot more resources to evaluating alternatives for redesign, and development process improvements rather than to re-gathering functional requirements, hand coding, and testing. They will ultimately enjoy a more maintainable system and a much more faithful reproduction of the original application functionality after the migration as well as greater control and visibility during the migration.
A trial edition of our tool is available here gmStudio Trail Request Download. It will allow you to experiment with ASP/VB codes up to 10K LOC and runs for up to 30 sessions.
There are 2 free ones that I use:
http://www.carlosag.net/Tools/CodeTranslator/
http://www.developerfusion.co.uk/utilities/convertcsharptovb.aspx
Microsoft recommends ArtinSoft’s Visual Basic Upgrade Companion (VBUC).
It's not perfect, resulting code still requires lots of manual fixes until it even compiles but still this tool is worth giving a shot.