Yesterday, while working on some Web clients, I caught myself thinking if only it were a Windows Form application… What I was doing would’ve been easier to do in a Windows Forms application (which probably applies to whatever you happen to be doing as well). However, because it was a Web application, I knew I had reached a small crossroad. Although the natural next step might’ve been to use a Windows Forms control in a Web page (which in the pre-.NET era was as simple as embedding ActiveX controls), something that technically can be done in ASP.NET, dynamic use of the Windows Forms control in a Web page is difficult and laborious.
In this article, you will learn the basics of embedding a Windows Forms control in ASP.NET and gain an understanding of why this isn’t the correct approach and why smart clients are. A smart client basically is a Windows Form application that dynamically updates client assemblies. This article introduces smart clients, providing you with enough information to explore them further and determine when you might need to employ them.
By the time you have finished reading, I hope you agree that Microsoft has an obligation to merge the two technologies, ASP.NET and Windows Forms, and completely hide whether one is programming for a network or not—it just makes good sense. From a user’s perspective, it shouldn’t matter anyway.
You may also draw the conclusion that smart clients indicate where technology is headed—no more script, no HTML, and no more code-behind, just GUIs and code like it was in the old days. Smart clients are a stepping stone on this journey; we aren’t there yet.
Adding a Windows Forms Control to an ASP.NET Page
Suppose you have a Windows Forms control that is either difficult to or too expensive to reproduce for Web Forms. You can use the actual Windows Forms control in a Web Form (ASP.NET) application by:
- Adding the Windows Forms control to a Windows Control Library
- Copying the Windows Control Library to the Web Application’s root folder
- Adding an <OBJECT> tag to the ASP for the page in which you want to include the Windows Forms Control Library
Building the Windows Control Library
A Windows Forms Control Library creates a .DLL project with references to the System.Windows.Forms assembly. This is an approximation to an ActiveX control library that you may be more familiar with from VB6.
Suppose, for argument’s sake, you’d like to use the Windows Forms calendar control in a Web page. You can add a Windows Control Library to an existing project by selecting Add|New Project from the Solution Explorer context menu and picking the Windows Control Library applet from the Add New Project dialog (see Figure 1).
Figure 1: Add a Windows Control Library project to a Web Application.
For our purposes, it is sufficient to drag and drop a DateTimePicker control to the UserControl (defined as System.Windows.Forms.UserControl) added to the Windows Control Library project by the project template. I renamed the UserControl class DateTimeUserControl. (It doesn’t matter what you call the UserControl namespace and class, but you do need to know this information later in the process.) When you are finished, your desktop might look something like Figure 2.
Figure 2: The Windows Forms UserControl with the DateTimePicker.
Embedding the Windows Control in a Web Page
The next step is to compile the Windows Control Library and copy the DLL assembly to the root folder of the Web Project (or Projects) that will embed this control. My ASP.NET project is named UseWinControl. As shown in Figure 3 (if you click Show All Files), the Windows Control Library will be positioned at a higher folder level than the bin folder.
Figure 3: Place the Windows Control Library in the ASP.NET application’s root folder, as shown.
Adding a project reference to the Windows Control Library won’t work because .NET will copy the output of the Windows Control Library to the bin folder, and you want it in the ASP.NET root folder.
The final step is to add an <OBJECT> tag to the Web Forms ASP. Add an <OBJECT> tag in each place and on each ASP.NET Web Form on which you want to use the control. The format of the <OBJECT> tag is shown in Listing 1.
Listing 1: The <OBJECT> tag for our Windows Control
<OBJECT id=DateTimeUserControl1 height=50 width=200 classid=http:EmbedWinControl.dll#EmbedWinControl.DateTimeUserControl VIEWASTEXT> <PARAM NAME="SelectedDateTime" VALUE="<%=DateTime.Now %>"> </OBJECT>
In the listing, I provide an ID for the control and its size. You’ll need to provide a class ID, which can be a URN or GUID. I used a URN (or URL) that includes the HTTP moniker and the relative path of the DLL followed by a pound sign (#) and the namespace and class of the control. The designer uses VIEWASTEXT to figure out how to show the text. Next, I provide any parameter values using the PARAM tag and close the <OBJECT> tag with </OBJECT>. The parameter is a public property I added to the UserControl; it simply surfaces the DateTimePicker’s Value property. (See surfacing constituent controls and properties in the VS.NET help for more information.) The result as coded is shown in Figure 4.
Figure 4: The DateTimePicker in a Web Form running in Internet Explorer.
There are real limitations to using Windows Forms controls in a Web application. The first is that the <OBJECT> tag does not support the runat=”server” attribute. This means no code-behind, which is a compelling reason to use ASP.NET in the first place. Consequently, you must manufacture dynamic interaction with your embedded UserControl using script. In practice, this means that you can set the date in the control but will find it very difficult to detect when a client has changed the date or determine what that date is.
Another real limitation is that, for a client to run this page, they must have the .NET Framework installed. There is no way to ensure that someone on the World Wide Web will or even can download and install the .NET Framework. This means this solution is limited to intranet applications where you can control the clients and ensure they have the .NET Framework. Collectively, the practical uses for embedded Windows Forms controls are very narrow and require a lot of work.
Introducing Smart Clients as a Better Alternative
When you find yourself desiring the flexibility of Windows Forms and the ease of Web application deployment, what you really want are smart clients. For all intents and purposes, a smart client is a Windows Form application that dynamically updates client assemblies using the Assembly class to download assemblies over HTTP. The result is a Windows Form application (that can talk to your server through Web services, for example), which can be deployed and updated over HTTP just like a Web application.
The ingredients you will likely need for a smart client application are the following:
- XML Web services to transport data back and forth between clients and the server
- An HTTP updater that automatically looks for assembly updates on your server and downloads them to clients
- At least a Windows Forms application kernel that downloads the assemblies initially and requests updates at some prescribed interval
Finally, clients will need to modify their security policies to support running downloaded assemblies, but the results are fantastic. Your customers will get a Windows Form application with all of the expressivity they will have come to expect, along with an ease of deployment like the Web provides.
Smart Clients Are the Right Approach
Some programming techniques are working solutions, but they really represent a bastardization or severe programmatic distortion of good practices. You can create a Windows Control Library to use your favorite Windows Forms control in a Web application, but dynamic use of the Windows Forms control in a Web page will be difficult and require a lot of programmatic acrobatics. It really isn’t the right approach.
If you find yourself needing Windows Forms controls, you probably need a Windows application. Build a smart client and download updates using HTTP and Web services to go back and forth between client and server. Internet clients will still have to download and install the .NET Framework soon, however—this will be a moot point. The .NET Framework will be as ubiquitous as any other framework (like Borland’s VCL or Sun’s Java).
You will need several skills to write smart clients, but they are not as hard as you might think. An excellent example of a smart client is the sample program IssueVision, written by Susan Warren and distributed at events such as TechEd this year. If you couldn’t make TechEd or need a copy of IssueVision, contact Susan Warren (formerly of Microsoft) at Vertigo Software (http://www.vertigosoftware.com).
Copyright © 2004 by Paul Kimmel. All Rights Reserved.
Paul Kimmel is the founder and chief architect for Software Conceptions, Inc. and a co-founder and President of the Greater Lansing Area .NET Users Group (glugnet.org). He has written several books on .NET and object-oriented programming and is available to build software for your company. You may contact him at [email protected].