Thanks for some good points and your insight.

>>As a developer I felt the one thing that is sorely missing from .NET is a data centric language such as dbase.
>
>But the goal of VS.NET is to take away power in the langagues. You shoudl be able to move from VB to C# and be able to do the exact same things the exact same way through the .NET framework.

I think the goal is being taken out of context. Yes you use the .NET framework’s classes the same from all languages but there is no need to loose the identity of the language itself just because you make it CLR compliant.

>>Also, that I could see no “technical” reason why the VFP runtimes (including the database engine and language interpreter) could not be ported to interface to the OS via the CLR and still maintain ALL of its functionality.
>
>But then you're defeating the goals of the .NET platform, and gaining absolutely nothing. Why woudl you want VFP code to run on the CLR if you have the exact same product, just slower and less reliable?

Slower maybe but less reliable, please. You actually consider VFP reliable now? I bet the C5 syndrome would disappear since VFP would not directly touch the OS. Granted these are mostly development environment issues and runtime VFP apps are “fairly” stable. Are you basing this on the fact that the CLR has an un-proven track record? My guess is that MSFT will make whatever investment is required to ensure a stable, reliable CLR. I have found the Beta-2 to be pretty darn stable outside of the stupid errors I tend to make.

>THe only reason I can think of is distributing your apps without the VFP7 runtimes. I think this can be solved other ways than porting the whole thing to CLR (a very timely and expensive manuaver).

Actually you would still have runtimes, they would simply be CLR compliant. Yes, the process would be very expensive and time consuming. That is one reason why it has not and will not happen.

>>You might want to ponder the benefits to VFP if it could run as VFP does today and have the ability for it’s classes to be used in any VS.NET application directly or vice versus.
>
>XML Web Services bridges that gap. As far subclassing a C# component in VFP... eh... I'm not totally buying that feature as earth shattering. Seems more like a maintence nightmare, but thats just me. In the Toledo Wish list I've actually requested that we do this. I'm think it would be like using an ActiveX control to contain the CLR control and we could subclass/play with that.

Web services are great and I’m glad VFP can participate. The .NET world does not revolve completely around the Internet. Did you know you could develop desktop applications with it to? A web service will do a lot of good there. How about when you need to return large data sets, it is neither an efficient or practical method. For most typical internet/intranet based applications I really would not want to use a web service just to access VPF’s data processing power. Kind of misses the point of providing a “Web Service”. Now if I could access a VFP class directly from any .NET language, that would be earth shattering to me. Actually, I could live without being able to use a .NET class directly from VFP.

>>Yes I can perform analytical data processing using the existing .NET languages, and write hundreds of lines of code. With a data centric language the task becomes much less daunting. It seems that the .NET languages and the framework’s System.Data classes are great at reading, writing, updating, filtering and presenting data. That’s where the designers dropped the ball. I guess they figured nobody does anything with data any more other than that.
>
>Or they figured that the databases themselves do the hard core stuff. SQL Server stored procedures? But either way, if VFP was ported to be a .NET language, I can say with confidence, that it would not fill in the hole you present.

Probably, but SQL Server is not the only data store in town. Makes porting apps across data stores rather difficult. What about multiple data stores? Putting the entire processing load on the data server is not always the best solution in enterprise environments. Well, from my perspective it would certainly make the hole much smaller.

In retrospect, I agree that porting VFP today may not be in its best interest from a VFP’ers viewpoint. I do see the .NET world looking at VFP as a legacy product that does not play in the sandbox.