Hey there,

Well, I have to disagree with Victor, but then I'm a Lead Program Manager on the VB.NET team. <g> First things first, though. Please make sure you have a business reason to move from VFP. Don't do it because .NET is cool, or whatever (though it is ;) ).

As far as which product to pick, I'll give you Microsoft's answer, then my answer. Microsoft's answer - pick whatever you'd like. Both languages give you the full power of the .NET framework.

My answer (and it's one reason I took this job). Both products are great. They each have benefits:

C# allows you to write unsafe code
C# is case sensitive
C# is closer to the IL (Intermediate Language) in the way you write code
C# has been submitted to ECMA as a standard
VB has a background compiler
VB has some higher level constructs
VB supports late binding
VB imports down to the class level

So, let's talk about these as a group and why I picked VB.

I don't care about unsafe code - I couldn't write it in Fox, didn't want to write it in C++, and don't need to now.

Case sensitivity drives me crazy - for instance, I type SQLConnection - which works fine in VB, but gives me a "CS1002: ; expected" error in C# because the class is SqlConnection.

C# is closer to the IL, but VB compiles to the same IL (with OPTION STRICT ON) so I don't care. This means I have some higher level language constructs like WITH...ENDWITH and the HANDLES clause of methods that makes event binding really easy for me - but I get the same speed as C#. I'd rather have the language constructs.

Late binding is another example - especially when I'm doing a quick utility, I like being able to do it with late binding and automatic casting. When I don't, I don't have to. Works for me.

VB importing to the class level is another time saver. If I import a utility library (like the VFP Toolkit for .NET - which I love and use), I can write code like:

DIM x AS String
x = FileToStr("c:\myfile.txt")

instead of

string x ;
x = strings.FileToStr("c:\test.txt") ;

The first *feels* more high level to me, and I don't have to remember what class library Kamal put the FileToStr() function in.

In terms of ECMA, that's up to you. Some people feel that makes a language safer, others feel it makes it slower to change as needed. I really don't care. Fox wasn't a standard, VB wasn't a standard, heck, Java isn't a standard either. <g> I always went with what solved my client's problems.

Finally, there's one other intangible - a number of the VB team worked on Fox over the years. Our Product Unit Manager, Rob Copeland actually was a Fox Software. One of our lead developers worked on VFP for a few versions. And I've been working with Fox since Foxbase 1.21 or so. Speaking for myself, as I work on the next versions of VB.NET I'm using all the knowledge I've gathered from real world development with VFP, VB and ASP over the years to make sure we build an incredible product...

So, bottom line - first make sure migrating from VFP makes sense for you. If so, pick a .NET product that makes sense for you. Either way, I think you'll be happy.

yag


>Our shop is looking at migrating away from Visual FoxPro and we are getting a lot of confusing information right now. How come consultants like Victor Campos are recommending C# over VB.Net? They seem to think that this is the only language with any future. Victor says C# is the better object oriented language with the better syntax and capabilities.
>
>
>Is this correct and what language is best? Can anybody offer any help here?