Auto-Deploying Windows Forms .NET Applications: The Revenge of the Fat Client

.NET provides new tools to make deployment of fat client .NET applications easier.This article describes the basics of .NET Auto-Deployment technology and the security mechanism that prevents users from inadvertently running code distributed by hackers and virus writers.

.NET Automatic Deployment is a feature built into the .NET Framework allowing applications to download assemblies (via HTTP) from remote locations on an as-needed basis.

With this feature, you can post your fat client application to a Web server and be sure that users automatically use the latest version the next time they run the application. Imagine that: No more CDs to ship with updates, and no more support calls from users that are a few versions behind!

The .NET Framework provides a lot of the functionality required for automatic deployment out-of-the-box. For example, .NET knows how to download an assembly from a remote location, cache it in the user's disk, and download it again only when a new version is available in the remote location. All these features come built into the .NET Framework.

Auto-Deploying an Executable

There are two pieces to auto-deploying a Windows Forms .NET application. One piece lets your users have access to the main executable. The other piece lets your users download the rest of the application as they use it.

Let's talk about the first piece. Giving users access to the main executable is fairly easy to do with .NET. You just need to post your executable to a Web server and let the users know the URL.

For example, let's say that you have an executable called loader.exe. You can create a virtual folder on your company's Web server and let the user know that the executable is available at http://www.mycompany.com/myapp/loader.exe.

Users can run the executable by pointing a browser to the URL (see Figure 1.) Users can also run the executable by entering the URL via the Run option in the Start menu. Or, you can create a Web page with an HTML HREF tag referencing the URL.

Let's run one of the .NET executables that comes with the downloadable files for this article:

1. Unzip the CodeDownloadDemo.zip file to c:\CodeDownloadDemo folder.
2. Create a virtual folder in IIS and name it CodeDownloadDemo
3. Map this virtual folder to your c:\CodeDownloadDemo\Loader\Bin folder
4. Launch Internet Explorer and enter the following URL: http://localhost/CodeDownloadDemo/loader.exe

See how the loader application comes up outside the browser? Once the application is running, you can even close the browser and still access the application.

You can do the same with any other .NET executable. Just drop it on a Web server and launch it with a browser.

Watch Out for UrlScan Tool

The example above runs seamlessly as long as you don't have the UrlScan Tool installed on your Web server. UrlScan Tool was distributed as part of the IIS Lockdown tool to stop invalid URL requests made to Web servers. By default, UrlScan Tool considers URLs invalid that include an executable name on them. So running the UrlScan Tool will deny access to http://localhost/CodeDownloadDemo/loader.exe.

You can detect whether you have UrlScan Tool installed in your system by reviewing the list of applications installed on your computer (Figure 2.)

You can also configure UrlScan Tool to allow requests for executables. To do so, modify the INI file that UrlScan Tool uses to detect valid and invalid requests. This file is usually named c:\windows\system32\inetsvr\urlscan\urlscan.ini. Below is a fragment of this file.

Notice that the .exe file extension has changed to .was_exe to indicate to the UrlScan Tool that .exe extensions are not to be denied. Keep in mind that this is a quick-and-dirty way of working around this restriction. You should read the UrlScan Tool documentation and consult with your network administrator before making this (or any other) change to a production Web server.

You might need to restart IIS after modifying UrlScan's INI file in order for IIS to pick up the change. You can restart IIS by running IISRESET.EXE program from the DOS prompt.

By: Hector Correa

Hector is Lead Software Developer at Epiq Systems in Kansas City. Epiq Systems is a leading provider of integrated technology products and services for the legal profession. Hector is a certified ScrumMaster and a Microsoft Certified Software Developer.

hector@hectorcorrea.com