>
Startup speed is the biggest issue. If .Net was not previously loaded and you start up a WinForm application you will sit and wait for 5 seconds before anything happens. For a commerical app this is a killer.
>

C'mon Rick.... Ever time how long it takes for Outlook, Word, Excel, etc. to start? How about tools like Goldmine, QuickBooks?? Even Fox can take about 4 seconds before you can actually get the command window. I think you are being a tad unrealistic here.


>
I started out with SharpUi on that app and that was terrible - with the form even under the best of circumstances takeing almost 5 seconds to load. Since I switched to Sandbar things look much better but still. I have several simpler forms that have roughly the same behavior though. The comparision in this case is almost one to one. Same exact UI (VFP using ActiveX controls - .Net using native controls).
>

I have not seen seen accross the board - 5 second start up times for forms - even complex ones.


>
There's no way that you're getting the same UI perf as VB6. VB6 was lightening fast with UI stuff especially load time (presumably because the OS somehow preloads the VBRuntime)...
>

I'll share some data with you off-line.... But in general, be careful with conclusory statements like "no way" - unless you are 100% familar with the circumstances.


>
Depends on what you talk about. ADO.Net sucks big time with large numbers of records because it loads everything into memory.
>

>
Try running a report that pulls in 100,000 records and sit back and wait for the data to be loaded into memory. ADO.Net was not build for large amounts of data pulled to the client. Microsoft has admitted as much in saying that much over 1000 rows is not an optimized scenario. While it's true that you should avoid pulling so much data all at once some scenarios (like reporting for example) require it.
>
For smaller amounts of data, though ADO.Net performs very well.
>

All good points...but what % of the time does one have to deal with 100K record report?


>
Ah, but I think that's not the right way to look at it. Perf can be slow for quite a while in the app. It's worst during startup but the problem is that everything is JIT compiled on the fly. Memory usage goes sky high because of this too as the compiler is actually part of your application. A WinForm app that does anything typiucally runs around 15 megs at startup, more if you dump a few controls on a form. This memory can be reclaimed later, but it's there to start with.
>

I am not going to argue that .NET has large memory requirements. But given the relative cheap cost of computing - so what? Its not like a moderately sized VFP app has a small footprint...


>
The other issue I see (and for me this is a big one) is that to build shrink wrap product .Net lacks a small data solution. If you sell to the personal market or even small business market you cannot expect to use SQL Server/MSDE. There's no local data solution. It's either you use local as in XML only or you use SQL Server - nothing in between.
>

I agree, shrink-wrapped apps is a yet to be resolved issue.