Friday, December 29, 2006

ClickOnce - Very Cool But Mostly Useless (At first glance)

I recently started playing with Microsoft's ClickOnce framework that was introduced in .NET 2.0. I had my own auto-update mechanism, but it's still pretty clunky and not as good as I wanted it to be, and I wanted to have a real install. When I came across ClickOnce it looked very impressive.
  • Auto-updating when a new version is published
  • Revert to previous version
  • Start menu and Add/Remove program support
  • Side-by-side execution
  • Auto generation of a web page for users to easily install your app
  • Ability to create "Groups" that can be installed on demand
That sounds perfect! Just what I'm looking for! After a little reading, I thought I'd give it a try. I created a test Windows Forms application and a dependent assembly. I enabled IIS on one of my computers so I had a place to publish to. Publishing is literally as easy as going to the project settings, selecting the "Publish" tab and clicking the "Publish" button.

My machine cranked for a bit, the files were transferred to the web server and the "Publish" page opened in my default browser. I click the "Install" button and I immediately come across the first problem - the install fails.

Bad thing #1: ClickOnce is not designed to work with any browser except Internet Explorer!

Not too big of a problem, I guess, as long as I'm aware of it and make note of it on my web site. After switching to IE and clicking on the "Install" button, it does some stuff and I have a Start Menu icon for my test program. I was anxious to test the auto-update feature. I made a small change to the main program and published again. The Publish feature of VS.NET 2005 is even nice enough to automatically bump the version number every time you publish!

With the new version in place on the server, I run my test program, the bootstrapper tells me there is an update available and ask if I want to install it. I choose to install the update and sure enough, the app has been updated. I can barely contain my excitement - this is so cool! I can't wait to test this with my [as of yet unnamed] program.

After going to the Publish tab in the project settings of my program, I check the files list and immediately notice that all of my plugins are missing! I look for a way to add the missing files manually, but don't see a way to do this in the UI. The first screen shot below shows the files in my output. I was expecting the "Plugins" directory and files below it to be picked up. Or, at the very least have a way of adding them by hand in the "Application Files" dialog (second screen shot below).


Bad thing #2: You can't add files that aren't directly referenced by your projects (or as far as I can tell, create an arbitrary directory structure)

My program uses plugins that are discovered and used at runtime via reflection. They live in a subdirectory of the main application folder and ClickOnce does not appear to include a way of creating subdirectories and placing files not directly referenced by the project. One thing I haven't tried is adding a reference to the plugin projects and setting the option to not copy to the output directory. I do the copy as a post-build step.

Bad thing #3: Where the heck are the files installed?

ClickOnce installs your program into a subdirectory of your "Documents and Settings/Local Settings/Apps". The full path is truly hideous and is different on everyone's machine. This is by design. In order to support the rollback feature, Microsoft wants control over the path to avoid name collisions and to make sure people don't install to parts of the file system that may require elevated permission to write to, like the "Program Files" folder. That said, if I wanted to tell a user to send me his settings file, how do I tell them where to get it from? Here's the full path on my system:

"C:\Documents and Settings\[me]\Local Settings\Apps\2.0\2JD5D4H3.AB3\5CWBKLHB.QNL\unna..tion_60261a46dfa9d898_0000.0002_713c372ded58c204"

Ain't that ugly? When I first tried to find where the application was installed, I went to the shortcut that was created in my Start Menu and looked at the properties. It *looks* like a normal shortcut, has the shortcut overlay, but doesn't appear to be pointing at anything.

So, it took a little bit of digging to find where ClickOnce put the files. Luckily, .NET provides an API to get the install location, so at least there is a way to provide access to my settings file in the program itself via a menu option, for example.

This is all truly disappointing. No control over where the files go and no way to add plugins, directories or other unreferenced files to the install set. And they're marketing this as a solution for deploying thick client/smart client apps? Unless you have a very simple app where everying lives in the same directory, you pretty much have to use something else. I don't know of many applications that fall into that category, unless they are corporate utilities or something like it.

I'd love to know how to do these things if you can, but from a couple days of reading and experimentation, I didn't see anything that would make me believe it could. If anyone reading this knows more, I'd love to hear about it!

Update: I did just find a tool that comes with VS2005, called MageUI, that seems to allow you to point at a directory and have it pick up all the files recursively. There looks to be a command-line utility as well that, I assume, can be used with MSBuild to do what I want. But, why didn't Microsoft just add the ability to do some of this in the UI built into VS2005?

Update 2: Found this article which provides information on how I can accomplish what I need to do. Again - why didn't Microsoft put that one extra feature that is so obviously needed into the VS2005 project settings!? Sheesh!

1 comment:

Robert said...

Now if only you could deploy with a browser that is slightly more secure than Swiss Cheese!