>I didn't know the answer, that is why I asked. Let's think this through. Why does more than one language need to be ported to the CLR if when they are ported they are virtually the same? <--- A statement I am still considering whether I believe or not.

They work the same, but they don't look the same. C# and VB syntax are _very_ different. C# will look familiar to a C++ developer, but alien to a VB developer. On the other hand, if you know VFP, you can pretty much read VB, if not program in it. The syntactical language differences are minor, and getting even smaller with VS.NET (no default properties, parens around parameters, Return statements, VFP's new AS keyword).

Between VFP starting to look more like VB, and VB starting to look more like VFP, removing VFP's cursor engine (yes, this is confirmed), EVAL(), COMPILE, macros, Deterministic Finalization (o.Destroy) and the rest of its xBase roots, adding support for WinForms, WebForms, free-threading and Garbage Collection, the move to have VFP write managed code would virtually make the two the same language. Why would MS choose to spend the resources on two different teams writing virtually the same product with different names? How would they justify that to stockholders?

Also, if it's realistic to expect MS to write a 'compile time option' for VFP, why don't you think that they would do this for VB? There is _much_ more legacy
VB code out there than there is VFP code, and many many more VB developers to worry about upsetting (and they _are_ upset)- if this was a viable option, they would have done it with VB.

>3) C#: Why invent this language? If as you say, "why not?" Isn't this pointless and a huge expenditure of money? If CLR languages become very similar we already will have two almost identical ones (VB and VC++) so why a 3rd? VB and VC++ (if compiled to CLR) will have already tossed their baggage and be lean and mean... in the CLR sense.

Like I said above, VB and VC will be similar in functionality, but still worlds apart in look and feel.

>Why did they bother with all of this effort? Wouldn't it have been simpler to choose only VC++ or VB to use the CLR... Or leave those two as they are and invent C# which will run on the CLR?

MS needs to move both languages forward. With C# they're hoping to attract some of the currently non-MS crowd. With VB.NET, they're hoping to keep the VB crowd (they wouldn't if they tossed VB). With VC.NET, they're hoping to keep the C++ crowd, all the while moving everyone forward with new technology.