Excellent summary Al!.

>>I'm not looking to start another marathon thread, but is there a definitive comparison bewteen VFP and
>>.Net anywhere?
>
>An overview of .Net: http://en.wikipedia.org/wiki/.NET_Framework
>
>A few high-level comments:
>
>- Perhaps surprisingly, in overall architecture .Net and VFP are similar. Both take source code and "compile" it to an intermediate form, then run that intermediate/tokenized code against a runtime, which provides an "application virtual machine" with automatic memory management, garbage collection etc.
>
>- There is only 1 choice for source language with VFP. With .Net there are several, with C# and VB.Net being the major ones; Managed C++, IronPython etc. are also available. You can choose one that fits the task and/or your programming style preferences, and mix and match them within a project if required.
>
>- So far, the languages available for .Net tend to be a little lower-level than VFP - if C# is, say a 4GL, then VFP might be a 4.5GL. You write more code to achieve the same thing using a typical .Net language.
>
>- VFP is loosely typed (you can easily change a variable from one type to another, you don't have to pre-declare them etc.). By default .Net languages are strongly typed, which has pluses and minuses. I understand .Net is or is going to offer some dynamic/loose typing support with the so-called DLR.
>
>- VFP is arguably still state-of-the-art for general-purpose "data munging", at least for data sets that fit within its capacities. .Net is still arcane/verbose in comparison (e.g. Thread#1266689 as an amusing example) but is improving. Some say that by writing suitable reusable classes in .Net the coding required can be made not much more than in VFP - but you have to either write that code, buy it from someone else, or hope that new MS technologies such as LINQ address these needs.
>
>- The scope of .Net is very broad, basically all of Windows. Unlike VFP it can be used for system-level and/or high-performance computing. IIRC Microsoft has, at least once, tried to write a complete version of Windows in .Net but couldn't get it to work (and/or perform adequately). This would be completely unthinkable with VFP.
>
>- There are efforts to make .Net run on platforms other than Windows - both by Microsoft, and others (e.g. Mono by Novell). These efforts are ongoing and a primary focus of development by both Microsoft and others. In contrast, VFP runs only on 32-bit Windows, although this environment can be provided by emulators on 64-bit Windows (i.e. WoW) and (technically) Win32 emulators on Linux (e.g. Wine), although the latter is legally prohibited by the VFP9 EULA.
>
>- VFP development has ceased (by Microsoft). There is no chance it will run natively on anything other than Win32. Personally, I'm concerned about issues running VFP on Vista, that have either not been addressed by VFP9 SP2, or that have been newly introduced by that SP. Incompatibilities with future MS OSs can only get worse.
>
>- There is at least 1 effort to effectively make VFP a .Net language, by etecnologia. Another effort in a different direction is Guineu by Christof Wollenhaupt - taking the tokenized code produced by MS's VFP9 and providing a runtime that runs that code directly against the .Net runtime. Whether either of these comes to fruition is not yet known. For myself, I would only consider using either if it could compile an app created using a major VFP framework such as VFE, and run it successfully.
>
>- Out of the box, VFP addresses only desktop apps. .Net also supports Web apps via ASP.Net. Various project types like this are supported within Visual Studio, with a lot of similarity in their look/feel.
>
>- On the other hand, out of the box with VFP you get a programming language, tightly integrated data storage/manipulation and a reporting engine. These are 3 separate things in .Net, which has both pluses and minuses. One minus is that with a typical .Net business app you may need to license and deploy a database server and reporting tool along with your .Net components.
>
>- For a product with a relatively small number of users, VFP has for a long time had a significant number of well-proven RAD frameworks available. For a long time .Net had effectively none, but this is changing; .Net framework vendors have had to deal with the much larger .Net scope and APIs (which is confusingly [from the POV of VFP] called the ".Net Framework"). Some people who have used both VFP and .Net RAD frameworks believe that the latter are now sufficiently proven and production-ready.
>
>I'm sure I'm missing a bunch of other points, and may be outdated or plain wrong on some of the above but it should at least give you an overview.