>Hilmar,
>
>I saw your follow-up post and wanted to clarify one of my original responses.
>
>My opinion on memory for the end-user was based on the presumption that you were installing the .NET framework on the client machine, and that users were running some type of Winform app in a client server or web-based environment.
>
>Obviously (as Bonnie pointed out), if the end-users are running something that's browser-based (Web Forms), then your requirements are generally the same as those for running Internet Explorer.
>
>There is another point - you can still have a Winform client-piece running on an remote end-user's machine, where that Winform client works with a web service, which in turn would work with your application layer/middle-tier, etc.
>
>As with any setup, there are several key areas of architecture that you'd need to hammer out (for example, managing result sets, disconnected record sets, etc.)
>
>This is the approach I've used the most often, where there are many remote users who have requirements for a rich UI, so much so that trying to fit it into a browser/Webforms is a huge challenge.
>
>In most instances, these users had a fat, monolithic desktop application for many years, and a Winforms/web-service architecture makes the transition comparatively more seamless than using Web Forms. However, your situation and requirements may be different.
>
>It comes at a price - the users must be running the .NET framework, and then need to have a certain amount of memory, disk space, etc.
>
>HTH,
>Kevin

Yes, your comments help a lot to clarify the situation for me.