Following on from my previous post on ClickOnce I had a quick look at programming against ClickOnce in VS.NET 2005. Here's the outcome...

There’s a new namespace in .NET Frameworks V2.0 named System.Deployment and it’s where you can find a whole bunch of goodies to programming against the ClickOnce technologies.

There are a lot of supporting classes in this namespace – so a good number of the classes are named *Exception and are scenario specific exception classes. Then there’s a bunch of *Handler classes and *EventArgs classes that relate to events that are fired from classes within the namespace.

There are 2 key classes that I could find within the namespace – ApplicationDeployment and DeploymentManager.

ApplicationDeployment lets you manipulate the ClickOnce bits so that you can be aware of things happening around your application and also so that you can take some control of how and when ClickOnce goes and checks updates etc. Remember that by default ClickOnce will go and check updates for the application post launch rather than at start-up time (to avoid delaying start-up) so you’re likely to have a running app with ClickOnce working away in the background.

You can get hold of an instance of the ApplicationDeployment for the current application by getting the static property;

ApplicationDeployment.CurrentDeployment

With an instance of the class you can work out details about the deployment such as RunningVersion, UpdateLocation, LastCheckForUpdateTime and you can go and kick ClickOnce to do work on your behalf through methods such as;

CheckForUpdate

DownloadFiles

Update

And asynchronous versions of these methods too. The async model follows the framework 2.0 model of providing you with an event that fires when the work is done. So, there are events such as;

CheckForUpdateCompleted

DownloadFilesCompleted

ProgressChanged

UpdateCompleted

In the case of the other class that we get to play with, DeploymentManager, the usage isn’t quite so clear. This class isn’t doc’d up on the MSDN site for VS 2005 and nor is it doc’d on the Longhorn site where it also appears.

From a quick look it would appear that this class is more oriented to taking control of the whole deployment process yourself rather than hooking in to a process that’s already begun.

What you’ll find however, if you create yourself an instance of DeploymentManager is a PlatformNotSupportedException gets thrown and a quick ILDASM on the assembly will tell you that the constructor for DeploymentManager has some code wired into it which calls a OnLonghorn property and throws if we’re not on that OS. So, we won’t be needing to know about DeploymentManager for a little while J I’d imagine that it’ll be removed from a later version of VS.NET 2005.