Mark Levison

Winforms Web Clients hosted in IE - useful tidbits

What is "Winforms Web Clients hosted in IE"?   Rather than use the ASP .NET model of controls that run on the server side and render to html, Winforms are downloaded to the user's machine and executed in their browser. 

Why is this useful?

1. Reduce the load on the server, since it will download components and push most of processing to the client side
2. Reuse - if your building a smart client desktop application, the same components can be repackaged to render in the browser
3. Server doesn't have to support ASP .Net - many of your clients be running Apache, Linux or even an older version of IIS
4. Latency - your user's don't have to wait for a round trip

What are the limitations:

1. User must wait for your dll's to download the first time
2. User must be running Windows and using IE
3. Your application must live within a restrictive permission set either the 'internet' or 'intranet' permision set

Articles that explain the basics: Using Windows Forms Controls in Internet Explorer and Host Secure, Lightweight Client-Side Controls in Microsoft Internet Explorer Also http://www.windowsforms.net/ has some useful resources.

Here is what I discovered through my research - these are all best guesses, so I include the observation:

1. AppDomains exit - only after the browser dies. (the back, stop or refresh buttons affect them). Evidence:
   • Statics persist over multiple invocations of an object (ie hit back button, reload the page and my static gets incremented).
   • Threads started in controls only finish when IE exits
2. Refreshing the page or returning to it with the forward button, start new versions of a control - but threads started by previous instances live on.
3. When either the back or refresh buttons are hit (or the browser exits) the control's dispose method is called (stop button has no effect). Therefore we can use the dispose method to tidy up any child threads.
4. Two controls on the same page share the same thread, statics et al
5. IE is blocked while the thread with the control is working. So use a background thread for all computations or requests that might block
6. If we use Application.DoEvents() on the control thread then IE will not appear blocked. Furthermore DoEvents() doesn't block if there are no events. All IE buttons appear to work when this is being called. BUT ***IE*** can't be stopped -- the processes dialog end task must be used.
7. If we use Application.DoEvents() during an api call then IE will not appear blocked. Furthermore this method appears to be non-blocking calls can be made without having to check if there are events first. All IE buttons appear to work while in DoEvents(), but ***IE*** can't be stopped -- the processes dialog end task must be used.

If you're application is running without full trust (either from the Internet or the Intranet), then you have to keep in mind some issues:

• Controls can use IsolatedStorage to save settings and prefences. However if you launch a full blown Rich Client (ie No Touch Deployment), it will not have access to these settings.
• The default Internet permission set provides the following restrictions are:
  1. no access to the system clipboard: so copy and paste only within the application, no drag & drop - at all
  2. top level windows display a warning banner
  3. access to the filesystem only through the default ("safe") File Open dialog
  4. no access to enviroment variables
  5. printing only via the default ("safe") printing dialog
• The default LocalIntranet permission set is more open, it
  1. full access to the system clipboard
  2. no warning banner around top level windows
  3. access to the filesystem only through the default ("safe") File Open and Save dialog
  4. provides access to the USERNAME enviroment variable
  5. Provides printing programmatically to the default printer, along with safe printing through a less restricted dialog box.
  6. a few other permissions which have never been useful to me (run caspol -l to see the entire list)

Update: I've just published a new article “Debugging No Touch Deployment apps“

If you want to see a no touch deployment application in action, see my posting: First Commercial .NET No Touch Deployment application

posted on Wednesday, April 14, 2004 10:08 AM by mlevison

---