John,

><<
>Now, as I had mentioned; in my particular case, since we distribute several hundreds of MB to each and every desktop (and provide ongoing updates via the Internet) continuing to use VFP as the desktop development platform makes sense. Once the Internet gets fast enough to satisfy our particular needs we'll be ready to move everything off the desktop to the net. It's just not the right time at this point.
>>>
>
>I wanted to address this issue specifically. I think the CLR is down to 12-15 megs. I am not sure of the exact number. I do know it is way down from the 100+ mb size that existed in Beta 1. From what I understand, the next versions of windows will automatically have the CLR. This is a BIG issue from a software distribution standpoint. All you are left to distribute is you EXE and/or your DLL's. Guess what - it will be simply a matter of employing the xcopy command. There are no registry entries to deal with. This is one of the big differences between ActiveX Controls and .Net Controls. .Net controls are built on top of the CLR. How these items get included in an assembly, I don't know yet. (I will find out soon!!). At worst, it is a matter of employing xcopy! Software distribution is going to get a lot easier.

Interesting. Still, copying several megabytes of data requires that the 'pipe' be big enough. I seem to recall in reading a recent talk Bill Gates gave that he suggested that the transport layer to and from homes (and I presume businesses as well) needed to be boosted. Once the net gets to a sufficient speed (the market will determine this I suppose) then the Internet has been reduced to a large network. Only security and training programmers to think in a stateless manner are the remaining 'barriers' I'd think.

Even with xcopy I will need to parse the data into a useable form. With proper n-tier development in hand I suppose it won't really matter what platform I use as long as I can meet my client's needs..

>
>One other thing, I don't see the future made up of all these browser-based interfaces. IMO, browswer-based interfaces solve a x-platform (this includes mobile devices). If windows is your platfor, IMO, folks will be better served by implementing windows forms and using the net as the "network".

Well... That all depends on the speed of the transport layer I'd think... Other than that I'd agree. Browser-based solutions are workarounds to overcome the slower speeds. Bump that speed up and your options reorient themselves.

>
>Therefore, I don't see applications moving away from the desktop. If anything, .net makes the desktop easier to use...

Well, neither do I. It's all about successful connectivity, of which there are several important compomnents which we've discussed. Speed, security, reliability, and so forth.


>
>
>>Also, what issues O/S-wise have you encountered?
>
>From what I have seen, .Net will make it a snap to build windows services. Also, the debugging tools in .Net are pretty sweet. For example, you can create your own counters that can be read by PERFMON. You can also, with the aid of .Net classes, read and write to the windows event log. There are a ton of OS integration goodies that .Net makes available to the developer.
>
>HTH..

Interesting. Yes it does..