When people decide to migrate their VB6 applications they eventually end up questioning where they should go. Is VB.NET or C# a good choice?
I have my personal preference, but my emphasis is in developing the technology to take where YOU want to go.
VB.NET is a VB dialect very similar to VB6. It supports several constructs and it makes the changes easier.
C# has several differences from VB6, but it has it a growing language with lots of enthusiasts in its community.
Obviously migrating VB6 to VB dialect is a task far more easier than migrating to a different language.
However we are a research company with years of work in this area and challenges is just what we love.
Let's use a methaphor here.
My beautiful wife, was born in Moscow, Russia. Like her, I really enjoy reading a good book. Some of my favorite authors are
russian authors like Dostoievsky, Tolstoi and Chejov. However I still do not speak russian. I have tried, and I will keep trying but
I still don't know russian. I have read only translations of their books, and I really enjoy them.
As a native speaker my wife always tells me, that it is not the same to read those books in another language besides russian.
And they are phrases (specially in Chejov books that I might not completely understand) but I really got the author
message and enjoyed it.
Translating a book from russian to a more similar language like Ucranian is easier than translating it to English or Spanish.
But I think everybody agrees that is a task than can be done.
You can use terrible works case scenarios, but these scenarios must be analized.
Let see (I took these example from the link in that Francesco put in my previous post http://blogs.artinsoft.net/mrojas/archive/2008/08/07/vb-migration-not-for-the-weak-of-mind.aspx)
If you have code like this:
Sub CopyFiles(ByVal throwIfError As Boolean)
If Not throwIfError Then On Error Resume Next
Dim fso As New FileSystemObject
fso.CopyFile "sourcefile1", "destfile1"
fso.CopyFile "sourcefile2", "destfile2"
fso.CopyFile "sourcefile3", "destfile3"
' seven more CopyFile method calls …
End Sub
and you translate it to:
void CopyFiles(bool throwIfError)
{
Scripting.FileSystemObject fso = new Scripting.FileSystemObjectClass();
try
{
fso.CopyFile("sourcefile1", "destfile1", true);
}
catch
{
if (throwIfError)
{
throw;
}
}
try
{
fso.CopyFile("sourcefile1", "destfile1", true);
}
catch
{
if (throwIfError)
{
throw;
}
}
try
{
fso.CopyFile("sourcefile1", "destfile1", true);
}
catch
{
if (throwIfError)
{
throw;
}
}
// seven more try-catch blocks
}
I think that the russian is really keep in this translation.
First of all. When you do a translation, you should try to make it as native as possible. So why will you keep using a COM function when there is an
equivalent in .NET. So why not use System.IO.File.CopyFile("sourcefile1", "destfile1", true); instead?
Second of all. The On Error Resume Next, I agree is a not a natural statement in C#. I really think that using it could provide results that are less predictable.
Why? Becuase after executing it, are you sure that all the CopyFile occurred successfully? I would prefer wrapping the whole code inside a try-catch instead of trying
to provide an implementation that is not natural in C#, will Aspect Oriented programming provide a clean solution for this cases. Maybe?
RPG and COBOL to Object Oriented Programming, PowerBuilder to C#, Hierarquical Databases to Relational Databases are just the kind of challenges we have faced in our research project.
Not everything is easy, and we might not be able to automate all the tasks (commonly due to the cost of implementing the automation not becuase of feasability).
But at the end Could you understand the whole novel?, even if you didn't understand the joke in the one of the paragraphs in the page?
My years of reading make be belive that you can.