ich client, (or in .NET terminology, "Windows Forms") applications provide a great user experience in terms of functionality, usability, operating system and inter-application integration. Unfortunately, they have also suffered from a relatively high total cost of ownership compared to browser-based applications, thanks to "DLL Hell", and a lack of automated upgrade capabilities in the operating system. Consequently, "dumb client" browser applications have become very popular, especially for distributed applications, even though they are generally not as user-friendly as Windows forms applications. But the .NET framework, with features like "Xcopy deployment", "the end of DLL hell" and "Web deployment" lets developers provide rich-client applications with all their functionality and ease of use, but without the higher cost of ownership.
This article describes the built-in deployment capabilities of the .NET frameworkand its shortcomings for rich client applications, and presents a class library that gives you the ability to add automatic upgrade capabilities to your .NET Windows forms applications.
.NET Framework Built-in Capabilities
The .NET framework supports the concept of Xcopy deployment
, which is the ability to install a .NET application by simply copying the required files to the target computer. It also supports shadow copying
, a process in which .NET copies each assembly into a temporary "shadow copy" directory before opening the assembly (DLL or EXE) file. This mechanism gives you the ability to recompile or to re-deploy new versions of assemblies while the application is in use. The new versions of your assemblies will be used the next time the user starts the application.
In ASP.NET applications, all that happens automaticallythe ASP .NET worker process does the work for you. So to update a Web application you can simply copy the updated files to the correct location, and ASP.NET automatically handles shutting down the running application and copying the shadow files. (It's only that seamless as long as your application doesn't use any assemblies requiring registration for COM interoperability, or assemblies that must be registered in the global assembly cache.)
Upgrading Windows Forms applications isn't quite as simple, partially because client installations are more complex. For example, Xcopy deployment doesn't create icons in the Window Start menu or on the desktop, nor do applications installed that way appear in the Add/Remove programs control panel applet or take advantage of automatic repair and other Windows Installer features. In addition, Windows Forms applications don't automatically shadow assemblies; loaded assemblies are lockedyou can't update a running application using Xcopy deployment. Instead, you must update either before the application starts, or update by shutting down the application and then using a different executable program to replace the updated assemblies.
However, you can
use shadow copying in your Windows Forms applications by creating an application domain (AppDomain) object and specifying a AppDomainSetup object with the ShadowCopyFiles
property set to "true".
Note that the AppDomainSetup.ShadowCopyFiles
property is a String type, not a Boolean, so the following code is incorrect (and doesn't work).
AppDomainSetup.ShadowCopyFiles = true
Instead, the correct form is:
AppDomainSetup.ShadowCopyFiles = "true"
This technique requires a stub executable, which remains locked during code execution (won't be shadow copied). For example:
' create a new evidence object,
' based on the current appdomain
Dim myDomainSetup = New System.AppDomainSetup()
myDomainSetup.ShadowCopyFiles = "true"
With AppDomain.CreateDomain( _
"sample", AppDomain.CurrentDomain.Evidence, _