Wiki Home

Should VFP Become DotNet


Namespace: Wiki
In the beginning of 2001 Mike Feltman started a discussion about the future of Visual FoxPro regarding Visual Studio.NET and created a wiki page named Should VFP Be In VSDotNet.
See also Should VFP Be In The CLR

The central point of that discussion was: Should Visual FoxPro continue to be a part of Visual Studio?

There he wrote:

"I recently had the opportunity to discuss whether or not Visual FoxPro should be included with Visual Studio.NET or made a standalone product again with some of the members of the Fox Team at Microsoft. The Fox Team is very interested in hearing what the community thinks about this. The following is my opinion on the subject. It doesn't necessarily represent the Fox team's opinion.""

"Visual Studio 7 or Visual Studio .NET, along with many other things, is the fruition of Microsoft�s long-term goal to have their development tools share a common IDE. In VS.NET VB, C++ and C# all share a common IDE and toolset. Previous versions of Visual Studio were nothing more than a bundle of Microsoft�s development products, but VS.NET actually makes Visual Studio itself the product and makes the choice of development language somewhat of an irrelevant afterthought. The one development tool that does not share this common IDE and cross-language capabilities is Visual FoxPro."

Some time has passed since then, VFP was taken out of the Visual Studio box, VFP 7 was released, followed by VFP 8 and VFP 9 (Europa) is almost here (its beta version is already available).

Regarding its future, Should Visual FoxPro become a dotNet language? (Not necessarilly getting back "inside" the Visual Studio box)
The Pros of Visual FoxPro becoming a dotNet Language:

The Cons of Visual FoxPro becoming a dotNet Language:


All the above cons, except the major rewrite part, are not true as shown by http://etecnologia.net. They have a compiler for VFP to .NET, Data Engine, VFP Forms, VFP Data Binding, USE data directly (SKIP, LOCATE, SCAN) and they are truly innovating in the Web Space. JamesClark
Comments:

Sorry, I don't know how exactly to edit a doc here. Hope doesn't mess. I don't care if it gets into the VS IDE or not. All I care is "cross-language" capability. If I could have a way to use .NET classes in VFP or any way to use .NET generated DLLs it'd be good for me. I'd love if I could use VFP generated classes in .NET. Free me from COM - that's all I want :) - Cetin Basoz

I agree with Cetin Basoz. I don't care whether it is dotNET, NETdot or dotdot. What I care is portable in any MS platform. Pls make VFP support WinCE, WebApp natively. Since other 3rd party vendor able to do so (ex. WC, AFP and ActiveVFP). Also, don't you think it is funny if MS product cannot run under MS platform OS?

Turn VFP into a .NET language but keep command window and keep backward compatibility... Metin Emre

I can do without some of the pre-VFP6 cruft that is still left over in the core. Define the strong points of VFP, and work them into your .NET compatible IDE and CLR. Yes, there is still a distinct need for desktop data crunching, and the web is still too slow to keep up with a good data-entry clerk. Randy Bosma [2008.04.07]

Who says you have to lose the data aspect of FoxPro to incorporate the language into .NET? If .NET had access to .DBF files (through FoxPro), that would be great for .NET developers, but bad for Microsoft as .NET applications would not need to use SQL Server anymore. FoxPro in .NET doesn't appeal to me as I like FoxPro the way it is. It would be nice to incorporate the strengths of a local database into .NET; especially the cursor (which is a direction that Microsoft is pursuing). When that happens, Fox will not have the huge advantage it does now over .NET languages. Todd Haehn

Ask yourself, "What makes VFP what it is?". There are several answers, but the one that comes up most often, and at the top of most people's list is "Data manipulation". To turn VFP into a .NET language would require that you lose that ability. VFP would use ADO.NET for data handling and lose it's #1 feature. VFP.NET would look very much like VB .NET. This has been discussed ad nausium for years and things won't change now.

I agree with better portability (vs. COM), but I do not agree it should necessarily become part of VS or even .NET - Don't forget, Web Services also provide for portability. Consider how much VFP has improved since it's been taken "out of the box". Don't think that would have happened if it was part of .NET or VS. -- Randy Jean

After being rather vocal about making sure VFP doesn't become a .NET language, and after seeing and working with .NET for a while, I've come to another opinion, and I hope noone minds me adding a 4th option below (See Does Anybody Remember Data for the reasoning behind it) -- Mike Helland

I thought about that too. The only problem I see is that .NET data access is through ADO.NET. Even if we have a "native" .NET access to dbfs, we lose all the xBase commands to manipulate them. This would render dbfs a lot less useful. -- Emmanuel Huybrechts

ADO.NET is native .NET access, and it will continue to evolve, so I don't see that as barrier. But if you think about it, the best way to manipulate DBFs would be through schema-driven business objects. Ideally, all the data manipulation code would be generated into business objects, whether it used ADO.NET or something else isn't important, as the data tier code would be hidden away from the developer in most cases. -- Mike Helland

Mike, this may be fine when you are requerying or updating the backend, but when you need to "munge" data locally (ie. after requerying but before dumping to a report), the cursor and it's related xBase commands are really nice to have. Needing to always do that through an object seems like extra overhead. We use an nTier framework so there is a mixture of this in our code. When we are doing OLAP type work we do a lot of SPT and use scan/endscan on the resulting cursor. Forcing me to create an object and talk to an object for this type of work doesn't sound very nice. -- Randy Jean

Why not if VFP is recompiled in C# instead of C++ ? VFP should continue to be an interpreted language and not a compiled language like every .NET language. -- Emmanuel Huybrechts

Because it would mean a rewrite, and because you can't just take a C++ project and compile it in C# since they are very different? And so on. Microsoft have stated that even to obtain a 64-bit version would involve a lot of rewriting.

I should be thick, I still (after all those readings and working with .NET for over a year and foxpro for many years) can't see why VFP should lose its data engine and ability to deal with local data directly to become a .NET language. After all local data is just another file (I don't mean I want it to be a .NET language) -- Cetin Basoz

Bill (William Sanders), also added my vote to Make 2 versions of VFP - one for Desktop Apps, one for the DOT NET CLR, having some things in mind, regarding what this voting option implies (at least for me), please check if that is what you meant:

(1) There still would be a VFP version keeping its characteristics and strenghts as those of current VFP8 or forthcoming VFP9, being mantained and supported by Microsoft (until 2010 or so), be it or not the last version of VFP as it is known today;

(2) A new VFP version (VFP.net) would be made available, somewhere in the future.

Think this would be the ideal solution but I understand that this is not a "wish list" to be sent to the FoxPro team, of course they already have their plans, can measure and determine all that is involved in a solution like this. My purpose here is to know what alternatives there are (or could be), the best ways to go and to discuss them with fellows that are in the same ship that I am. - Fernando Alvares

Let .NET bods access our data effectively in my opinion. For years, Fox hasn't wanted to talk with other languages, mostly due to data driver issues. The Time has come to open it up to all, good Ole DB drivers were a start but we need more inter-op here Tim Hustler


The Future of VFP
VFP is a great language with all the benefits that we know already that needs a better future. As technology and the world moves forward, VFP should move with it. The best platform to do that is .NET given that VFP is MS's product.

VFP is just like Visual Basic and C, the substantial majority of new functionality over time will not be changes to the language but will come to these languages through new controls/classes/COM interfaces provided by .NET and other vendors. Therefore there are a few things I think need to happen to VFP:
This could be done as additions to VFP (e.g. Super Sedna) without creating two versions of VFP.
Ben Creighton
Votes:
  1. Turn VFP into a dotNet Language: Metin Emre Mike Collins

  2. Keep VFP in as it is:

  3. Make 2 versions of VFP - one for Desktop Apps, one for the DOT NET CLR. -- William Sanders, Fernando Alvares

  4. Neutral - Undecided: Randy Jean

  5. Build in a developer's choice. .Net or Classic VFP: Grady McCue

  6. Evolve VFP into a .NET Class Library written in C# that offers the .NET Developer native access to the DBF/DBC: Mike Helland Tim Hustler

See Also: Should VFP Be In VSDotNet, Should VFP Be In The CLR

Originator: Fernando Alvares (june 22, 2004)

Category VFP Future
( Topic last updated: 2008.04.10 11:46:56 AM )