Hi Bob,

>Sure it does... as someone said to you, I can do some stuff in VFP in 3 lines of code, that would take 10 or 15 lines of code in .Net (of course VS.Net writes alot of that code for you.)

>I just wanted to point out that it balances out with the things you can do in .Net in a few lines of code that would take ALOT of code in VFP. Or, is not even doable in VFP.

>One case in point, and this is espesially relevent for Desktop apps is multi-threading. In a .Net app you could have backround processing, for example lets say printing. Your user wouldn't have to wait for a report to process cause it would be done on another thread. You can't do this in VFP at all!

Sure, .NET has advantages too in this area, but of course how often do you need such background processing job ? And if you really need it, would starting a seperate process not be a solution too, though it is not as *CLEAN* as a multi threading option. TO be honest, for the average and even advanced VFP application developer I don´t see much value in this argument.

All of course is about which platform is most suitable for developing desktop applications. There are many criteria involved to make a proper comparison and not all arguments have the same weight.

As I expressed before, I find the data munging capabilities of .NET just terrible because of the absense of a local dataengine, which is esspecially important to me when writing advanced desktop applications. I don´t want to manually iterate through collections of ADO.NET to mung my data, nor do I want to use an external source for it (SQL server) for network load abnd performance reasons. In what respect: what does .NET have to offer me. Virtually nothing....

It is exactly in this area where a few lines of VFP code is equal to many lines of code in many other language. The local dataengine makes it possible to process and datamine lots of data very quickly in just a few commands.

>You can use 'zero touch' deployment with .Net windows forms app. The app will look to see if there is a new version of the assembly it needs on the server, and if so, it will download it automatically. Sure, you could do it in VFP, but you would have to code it, .Net builds this in.

I´m not sure what you say here? but are you refering to automaticly look for updates. This is certainly not complicated and in fact I think many VFP developers use such strategy.

>In .Net you can write your assemblys against a certain version of code, say your class libraries. Then you can update your class libraries to a new version, install it side-by-side on the machine with the old version, and deploy and app that uses the new version. No dll version hell.

My class libraries are built in the executable, so no problem here also. For application dependant resources, you can store them in the working directory to prevent versioning problems.

>.Net apps run in the CLR sand box, so the user can set permissions on what that app can do, so they don't have to worry about your app deleting critical stuff.

>Other than the .Net runtime... your .NEt app doesn't even need to be installed. Just drop it into a folder on the pc, and launch the EXE. All of the settings and meta data are in the .DLL... no registry settings needed. If you do need that stuff an XML (text file) config file is there and you or your user can easily edit it as needed rather than fighting the registry.

Other than a universal VFP workstation setup you don´t need to do this for a VFP application as well. I don´t know about .NET, but of course, VFP versions do not conflict eachother....

>>>Of course, there are alot of things you can do in .Net with 3 lines of code that you can't even do in VFP!!! (Well, you could with a few hundred lines of code and the Win32 api or a Win32 dll.)

Of course! However, It is the question how relevent the ´thing´ is.

Walter,