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