Some notes on ClickOnce

In my sessions on smart clients the past weeks the ClickOnce seems to be the topic that generates the most questions. I'll try to clarify some of the issues here.

Application Permissions and ClickOnce

One of the main concerns people have is how a user knows what rights an application gets when it is installed via ClickOnce. To understand how this works we need to have an understanding for Code Access Security in the .NET framework and how it controls application authorization.

There are actually not an option to let users evaluate what permissions an application should have. Imagine my dad trying to figure out whether "FileIOPermission" is something good or bad for his latest "Amazing AdOffer For U Only Today" application somewhat involountarily downloaded from somewhere on the web.

The application code can define what permissions it require and if they are not provided by the runtime an exception will be thrown. We may catch these exceptions runtime and display errormessages to the users informing about the lack of permissions, and maybe why our application requires them. But it's not a task for ClickOnce.

Each application is installed and assigned to a policy based on the evidence it presents. This is typically url-evidence for intranet scenarios. When the application presents evidence based on www.mycompany.com and I've got a security policy for this evidence the application is allowed to do certain things. This works much like trusted sites in internet explorer.

So what do developers have to do to assert that their applications get sufficient rights? CAS operates with three levels of policy: Enterprise, Machine, User and Application Domain. These policy levels contain Code Groups which consists of a permission set and a membership condition.

For a typical intranet scenario the Enterprise policy level would conain a code group with a membership condition set to the internal ClickOnce publish location, or it's base url. This way we'd be able to define what applications published by ClickOnce on this URL can do on in the Enterprise through permission sets. The security policy is evaluated top down, so users cannot extend the local machine policy beyond the Enterprise policy level.

You can also specify what permissions your application requires through the project security settings in VS2005.

Code Access Security is one of the more complex areas of the .NET framework, and I strongly recommend developers to start reading up on it.

Complex deployment scenarios and ClickOnce

Another common question on ClickOnce is related to complex deployment scenarios. This is a two-fold issue. One is the capabilities of the new Visual Studio 2005 setup projects, the other is the code you'll still need to write in your installer classes.

The setup project in Visual Studio 2005 Beta 2 is a sad story. As far as I can see the only improvement is that default registry keys have been added to the registry editor. Otherwise it's all the same. The vdproj files are still there in the same format. Currently vdproj support is on the community MSBuild wish list, but what they really should do is to create a neat xml format do define deployments and setup projects.

For installer classes the same CAS restrictions apply as for the actual code. If you need to perform database operations from code in your installer you'll need to be granted the appropriate permission (i.e. SqlClientPermission). The big drawback however is that advanced installation operations are not supported by ClickOnce. There are key differences between Windows Installer and ClickOnce that you must consider for your application. "Choosing between ClickOnce and Windows Installer" is a good read.

However you can combine the two technologies and get the best from both worlds.

The limitations of ClickOnce makes it suitable for more light-weight client applications such as the ones I've described earlier. Hovewer for more complex deployment it's wither not an option, or you can construct hybrid solutions with a Windows installer based host that aggregates the separate task oriented smart clients (much like the Composite Smart Client stuff by David Hill) which in turn uses ClickOnce to keep themselves updated.

What happens then the publishUrl changes?

A final issue on ClickOnce was the inevitable "What happens when your publish url changes". In the simplest case you'll probably be able to publish an update to your application on the original url with a modified updateUrl pointing to the new location. Running side-by-side for a while will update most clients. When you eventually remove the original url the remaining clients will call the administrator when they discover that they're missing the last years updates to the application that all their colleagues are enjoying. This will always be a manual thing. Hopefully you've got the current publish url available from a logical location on the web so users can navigate to the new url themselves.

Also, if the publish url is significantly changed (from www.mycompany.com to www.giantmerger.com) you might also experience issues with Code Access Security if policy is based on URL evidence, so in that case you'll need to update CAS policy aswell.

ClickOnce and MSBuild

Doing application publishing from the development machine is not a feel-good thing for us buildserver evangelists. You don't want to publish something that haven't been through a comprehensive set of tests in the right environment, so publishing directly from VS.NET 2005 is probably not the way to go in many cases. Fortunately we're now getting MSBuild, and you can publish from the command-line.

Trying out ClickOnce in Beta 2

So you've decided to try it out. Personally I experienced issues then publishing the application related to a couple of missing MIME types in the IIS vdir settings for the publish location. In addition to a problem with the .manifest file type I also had to add a MIME type for .deploy (as application/octet-stream). You have to do this either on your virtual server or on the virtual directory under Properties > HTTP Headers > MIME Map.