In my previous article, we discussed the opportunities for Smart Client development in the enterprise, enabled by the registry-less run style of managed code. In this article, we will flush out the details necessary to successfully deploy a managed Smart Client application.
Click Once Deployment
One choice for deploying Smart Client applications is Click Once Deployment. This enables your entire application to be deployed from a network share or website. The .Net Framework can be bootstrapped into the install process, the user gets a nice little desktop icon, and the application is registered with the Add/Remove control panel applet.
When Click Once Isn’t Enough…
The Click Once model falls short when the deployment requirements get more complicated. For example, I have a client for whom I wrote a rather complex financial package which they then sell to their customers. The application is divided into four modules. The customer can purchase various combinations of those modules. My client didn’t want any of the modules that a customer didn’t pay for to reside on their computers.
Certainly I could have set up a separate Click Once install site for each customer. But that would require recreating all of the deployment packages every time we upgraded any part of the software. This reminded me too much of DLL-Hell and was not viable long term.
Creating an MSI file was out of the question, since there wasn’t any way we could physically get onto those machines ourselves and my customer didn’t want to deal with sending out CDs.
Creating my own solution seemed to be the only way to handle the more unique requirements, but that also meant I would have to manually ensure that we:
· Installed the .Net Framework if it wasn’t already there
· Created an Icon on the Users’ computer
· Selectively download the correct current assemblies the first time the application starts and whenever they were updated
A Hybrid Deployment Solution
My solution was to create a hybrid solution that used Click Once to get the framework, icon and uninstall registration taken care of and some custom code to do the ongoing updates. I still created a Click Once deployment for each customer but the only time these had to be redeployed is if the Launcher program changed.
Base Application Install
The first step is to create a Windows Forms\WPF application that will be deployed via Click Once. This application contains no business logic or references to any part of the actual line of business application but contains the code to do the updates for the business application.
By deploying this file and its app.config through Click Once the users get their icon, the .Net FW gets installed and IT (which is usually me for these clients) doesn’t have to touch the computers.
Application Updates
In addition to any configuration information that the application needs to do its job, the application configuration file also contains the server location where the latest assemblies are housed, the name\location of the manifest file\service, a security token (actually several but for this article I am rolling them up into one) and the fully qualified name of the startup object.
Each time the user starts the application Click Once checks to make sure the launcher executable and the configuration files are up to date. The launcher application downloads the manifest file from the server, loops through the data contained in that file downloading any updated assemblies to the user’s computer. When the updates are complete the startup object gets called and the user is using the most current release of the line of business software.
There are just two core components to this architecture; the application launcher and the application manifest.
Application Launcher
The application that is deployed through Click Once can’t reference any of the line of business assemblies. If it does the application will not be able to update them since they would be considered in use and locked by the operating system.
The role of the launcher is therefore very straight forward:
· Copy the Manifest from the server OR call out to the manifest web service
o If using the file approach you could leave the manifest on the server, but then performance tanks. If having the file on the local machine is a security concern. Encrypt it or use the web service approach.
· Determine which files in the manifest apply based on the security token and copy them to the local machine
o Security in this process is location based, not user based.
· Use reflection to load and start the line of business application.
Application Manifest File/Service
The manifest can either be delivered as a file from a network store or through a web service. Which approach you use is dependent on your situation but the concept is the same for both approaches. The manifest contains the group security information and the assembly detail.
For each assembly in the application the manifest contains:
· File Name
· Version
· Date Modified
· Server Location
· Module Group
The security token coming from the client computer is validated against the security requirements for each assembly group. Groups that pass the security check then get their related assembly information loaded into the launcher.
The launcher looks for each of these assemblies on the local drive, compares the version and last modified date of the assemblies to those documented in the manifest and copy them from the server if they are out of date or missing.
TIP: Probing Path
I set up a probing path for all of my Smart Client applications to keep my directories tidy (I like only having the startup exe and the configuration file in the application directory). This also greatly eases the deployment process since the update code knows exactly where the assemblies should be located.
TIP: Build Process
I have helper apps that run when I “Build for Deploy.”
This process does the following:
· Increment the version number
· Rebuild the entire solution
· Obfuscate all necessary files
· Copy finalized assemblies to a staging area
· Create the manifest information
Conclusion
By combining the two deployment strategies you are able to take fine grain control of your deployments while still getting the benefit of having someone else (e.g. Click Once) deal with the mundane setup tasks that are a required part of any .Net deployment but don’t add value to the customer.
Phil Japikse has been working with .Net since the early days, and developing software for over 20 years. Specializing in application architect and agile methodologies, Phil helps clients with eCommerce sites, shrink-wrapped and/or internal Smart Client/WPF applications, coaching teams in their transition to agile, and also teaches classes on Test Driven Development, Patterns and Practices, and various additional topics. Phil is an active member of the .Net community, serving as a director for the Cincinnati .Net User’s Group and Software Architecture SIG, speaking throughout the Heartland for Code Camps and User Groups, and nationally at conferences such as VSLive. A Principal Consultant with Pinnacle Solutions Group, Inc. (www.pinnsg.com - a Senior level firm specializing in Custom Software, BI, and eCommerce solutions located in Cincinnati, OH), Phil is an avid .Net Application Architect, Developer, Speaker, and Trainer. Phil is also a contributing author for www.NPlus1.org, a site by architects, for architects. Phil currently holds MCSD.Net, MCDBA, and Certified Scrum Master certifications. Phil also serves as a Firefighter/Paramedic/Instructor for the local fire department and volunteers for the National Ski Patrol. You can follow Phil on twitter via www.twitter.com/skimedic and read his blog at www.japikse.blogspot.com.
Subscribe (RSS)
