Well, I have to disagree with Victor, but then I'm a Lead Program Manager on the VB.NET team.

Your disagreement seems more politically driven. You even admit the fact that you are the lead program manager on the VB.NYET team. I wonder what your answer would've been had you been the lead on the C# Team.

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 ;) ).

This statement seems emotionally driven. But put that aside and looking at the business reasons:

2GB Table Size
Having large amounts of data tends to be a real problem when you're reaching the limit size of a table. SQL seems to be the only other alternative if you want to remain a Microsoft shop. Once you've made that move you now have to use Remote Views and ODBC which tend to have plenty of overhead (I'm sure you're very familiar with this, YAR). Now, comes ADO.NET which promises all this ease of use and performance. Is it there, yet? I don't think so. VFP BizObj's with C# are probably the best mix - for now. We'll have to see how Microsoft plans to improve the performance on ADO.NET.

Poor Object performance by VFP
VFP has always been a "hog" when it comes to UI. Not only that, it also has problems when it comes to working with ActiveX Controls - although VFP7 has improved on that, I've found that C# is more promising when it comes to UI and Windows.

under the hood VFP is not really OO
Alot of VFP is written in C and some C++ (I wouldn't be surprised if you told me it also had some VB in it, also - which doesn't even come close to OO). This isn't really a reason to move away from VFP since VFP provides some very useful OO features. But I was truly disappointed when I found that the VFP Team misinformed the community.

Poor support
The writing is on the wall - everyone at Microsoft as well as well known 3rd party VFP vendors have shifted their resources to .NET. This could be interperted in two ways: Here's a chance for new up and coming VFP vendors or jump ship because resources are quickly depleting for VFP. Which is it, YAR? To add salt to the the wound, certain Microsoft VFP Team members are not even advising people to stay with VFP but rather encouraging them to move to VB.NET. <g> I wonder who gave them that idea?

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.
Once again, the writing is on the wall. Microsoft themselves are have plenty of articles saying that C# is the evolution of the C Programming language. C has been around for at least 2 decades longer than VB. It's a well structured language that will assist even a new developer learn proper programming. Sure VB is alot easier for creating "quick" utilities - but why? If I can create "quick" utilities in VFP.


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
I disagree - C# is the better language. Why didn't Microsoft choose VB.NET to submit to ECMA? Because C# would be easier to port to other platforms. Why create two languages that are equally powerful? Reality is that they are not equally powerful. .NET is very new and not all power features have been discovered. For now, a well structured language, closer IL relationship and the submition to ECMA is reason enough to choose C#.

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.

This is a weak example

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.

Sad to see a Microsoft representative mislead the community. C# and VB.NET DO NOT (I repeat - DO NOT) compile to the same IL. They compile to similar IL - NOT the same.

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.

Why would I want to know that I'm missing a class at runtime? Late binding affords you that capability. However, I'd like to know that something is wrong at compile time. Again, quick utilities - I can do them in VFP. Why do I need VB.NET? Or are you know down grading VB.NET for "quick utilities" and not for Enterprise Applications?

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") ;

Once again, you're misleading the community. The "using" clause in C#.NET is similar to the "import" clause in VB.NET. Stop misleading the community with poor examples. If you're gonna recommend the use of a particular language have your facts straight.

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...

C# works just as well with VFP. In fact, I've been working with inter-operability between C# and VFP - I haven't experienced any problems what-so-ever.

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.

Thank you. Keep in mind that this transition is not a full transition. VFP will still be used in the middle tier. This is only to get into position should Microsoft pull more resources from VFP. That's a real business approach.