<cut>
Quote:
> 1. You don't lose anything by running the upgrade wizard. Let it run
> overnight if you can't afford to let one of your computers process it for
a
> while during the day. When the wizard is done you will have a new VB .NET
> project with a todo list of things that it couldn't upgrade. If the todo
> list is short, then maybe the upgrade process will be relatively quick and
> painless. If the list is long, then you can think about if you really do
> need to upgrade this project or just leave it in VB6.
There are some "gotchas" however. One I can think of off the top of my head
is that DateDiff.
Take the following VB6 code for example:
Private Sub Main()
Dim d1 As Date
Dim d2 As Date
Dim l As Long
d1 = CDate("Jan 1 2002 11:00PM")
d2 = CDate("Jan 2 2002 01:00AM")
l = DateDiff("d", d1, d2)
MsgBox CStr(l), vbOKOnly, "Days"
End Sub
The Upgrade Wizard gave me this:
Public Sub Main()
Dim d1 As Date
Dim d2 As Date
Dim l As Integer
d1 = CDate("Jan 1 2002 11:00PM")
d2 = CDate("Jan 2 2002 01:00AM")
l = DateDiff(Microsoft.VisualBasic.DateInterval.Day, d1, d2)
MsgBox(CStr(l), MsgBoxStyle.OKOnly, "Days")
End Sub
The problem is that the result in VB6 is +1 while the result in VB.Net is 0.
I could argue that either is correct, but the difference introduces
potentially subtle bugs in code, especially in large projects.
My take on the upgrade wizard is that it's useful for getting pointers on
how to rewrite sections of code but what I think I'd do is run it and save
the project to the side for reference and then start over, testing each and
every procedure thoroughly.
Also, if I'm going to write code in VB.Net I'm going to use the dotnet-style
syntax and not the VB Classic syntax:
Public Sub Main()
Dim d1,d2 As Date
Dim l As Int32
d1 = Convert.ToDateTime("Jan 1 2002 11:00PM")
d2 = Convert.ToDateTime("Jan 2 2002 01:00AM")
l = d2.Date.Subtract(d1.Date).TotalDays
MessageBox.Show(l.ToString, "Days", MessageBoxButtons.OK)
End Sub