I'm sure they are - I KNOW they are - and perhaps that's my point. If VFP team is getting tight with the VB .Net team - especially if that's where they're gonna land one day - then that would explain the bias I'm seeing

I see this as cross-pollination - the same thing that's been happenning for years at MSFT. I don't see any indication that the VFP team is boxing up their stuff so they can move over to the VB.NET building on campus.

Wow - I guess I'm having no problems with namespaces in C# - certainly no harder than a "set classlib to" in VFP.

Well, I meant "easier" as in "slightly easier." Have you worked with anything but the .NET framework classes yet? If not, then I understand your statement. But if you build your own classes as a separate assembly and then import them into a VB.NET program, you don't have to preface the method calls with the namespace name or an alias, like you do in C#. The VFPToolkit brings this to light also. It's a simple thing, really, but I think my code is cleaner without that stuff. For a test, try importing the Microsoft.VisualBasic namespace into C# to see what I mean. I did that as a test so I could use the VAL function instead of System.Convert.ToInt().

I just spent some time seeing quite a few things C# did that VB either didn't do or didn't do nearly as well - I would have to go back and look at notes to tell you all the details - but my point is that the "easier/better" thing probably works both ways.

Absolutely agreed here. I don't mean to make it sound as if VB.NET is the best language since the dawn of time. I'm just trying to point out where I've seen its advantages. And to assimilate you into the fold. <bg>

Now this may be a good point! But, exactly why do you think it is easier to use in VB? What is difficult about using it in C#? It's just a set of classes, right?

Pretty much because of the namespace issue I brought up above.