Back when ASPWatch.com was running, I wrote several articles covering Active Server Pages for them. I grabbed the following web pages off their site before it was shut down.

• Caching Select-Box Data
• Creating Aliases to URL’s
• How-To Color Banding
• Javascript Search and Replace
• Make HTML Combo Boxes Behave Like VB Combo Boxes
• Quick and Dirty Form Processing
• Returning Ad-Hoc Queries in HTML Tables
• Using Javascript to Dynamically Populate Select Lists
• Using Persisted Recordsets to Page Through Large Query Results
• Using SQL to Write VB Code for You
• WordWrap Function

I recently completed a .NET WinForm project for one of our clients, a parts management and bill of materials system. Having spent many years doing ASP and ASP.NET web applications, I found many aspects of the WinForm application appealing: application speed, state management, printing, and just overall better control of the client application and the user’s experience.

However, WinForm apps have a major drawback when compared to web applications: deployment. When there is an update to a WinForm app, it needs to be distributed to all the desktops that are running it. Depending on the size of the organization, this can be a daunting task.

So I spent some time tonight playing around with a “self-deploying” and “self-updating” application and found that it’s pretty easy (even without using the Microsoft Updater Application Block).

Here’s the basic setup:

1) A WinForm application compiled as a DLL. You can do this in VS.NET under the project properties, General, Output Type, Class Library.

2) A web service running on IIS. This will provide the information on which files the client needs as well as the files themselves.

3) A “wrapper” application which retrieves the client information and files from the web service and executes the application.

First, our client application. I’ll skip the code here and just give you the basic details. We have a sample “Business Objects” assembly with a GetHelloWorld method and a WinForm app compiled as a DLL. This has a form with a button that calls the method on the business object. I did this so we’d have two DLLs that we would need to download for this sample.

Let’s take a look at the Web Service. It consists of a SmartClientDefinition class and a
GetSmartClientDefinition method.

View SmartClientDefinition class

Our GetSmartClientDefinition method just returns the information needed by the client: which files to download, which assembly to load and which instance to create.

View GetSmartClientDefinition method

Our wrapper application is just an EXE that calls the web service, downloads the assemblies, loads up the main assembly and instantiates an instance of our HelloWorld form.

View SmartClientWrapper class

To deploy our hello world app, all you need to do is put the DLLs on the web server in the same folder as the web service and distribute the EXE to your desktops. When it runs, it calls the web service, gets the files and runs the WinForm application. When you need to update all the desktops, all you need to do is copy the updated DLLs to the web server and they will be deployed the user runs the app.

Keep in mind that this sample is very basic and doesn’t support a lot of the functionality that is built into the Microsoft’s Updater Application Block, which will handle pretty much any deployment scenario you can think of. This is just to give you an idea of how you can roll your own deployment/update scenario if need arises.

You can download the sample code here.