My experience with both VB and VB.NET and VS is that you can easily get your
VB code to *work* in VB .NET, but that doesn't mean that the code is in any
way efficient or taking advantage of .NET's true power. Simply turning on
the extra compiler checks doesn't force you to abandon legacy VB functions
in favor of .NET framework objeccts and methods.
A perfect example is the VB C***() conversion functions, which are designed
to take in any data type (make that object in .NET) and return back the
desired data type (make that object in .NET).
When trying to go from a value type to another value type (like integer to
long integer), excessive boxing/unboxing occurs. This will *work*, but far
more efficient is the .NET convert class, which has many overloaded To***()
methods, each one written to accomodate a particular input type and avoid
these unneccessary boxing/unboxing operations.
In the end, if you really want an application to take advantage of all that
..NET has to offer, the brutal truth is that you shouldn't try to convert the
application, you should rewrite it. Of course, that is not always practical
and so, we wind up with a lot of poorly written VB.NET that started out its
life as VB 6.0.
I work with many companies that outsource the coversion of their VB 6.0
applications and when those applications come back (from India usually),
they run slower and have more bugs than before they were converted. This
leads many managers (who aren't programmers) to the incorrect conclusion
that .NET isn't worth the hype, when in fact, they're just dealing with
poorly written code, which you can write in any language for any platform!
-Scott