What's the Downside?
Despite the simplicity apparent from the sample application, early users of ClickOnce sometimes had problems with end-users getting the most recent updates of their files due to Internet Explorer's caching behavior. A developer I know had to instruct his beta-testers to force a "hard refresh" of IE by pressing Control-F5 to make sure they had the latest files. However, it appears this issue has now been solved by the ClickOnce team.
The same developer found ClickOnce incompatible with the obfuscator he uses (RemoteSoft's Salamander), and there have been reports of people having problems using the DotFuscator Community Edition software that ships with Visual Studio 2005 with ClickOnce.
Brian Noyes has successfully used ClickOnce with a .NET test application. He first created the application, published it with ClickOnce, then obfuscated the files and updated the manifests using the Mage tool. Using that procedure, he was able to publish the now obfuscated program via ClickOnce successfully.
|Author's Note: At the time of this writing, neither RemoteSoft nor PreEmptive had responded to my technical queries about using their obfuscators with ClickOnce. Please see the sidebar "ClickOnce Open Issues" for a brief interview with Adriaan Canter, Microsoft's Dev Lead for ClickOnce, and for more discussion of obfuscation issues.
Some developers found that lack of compression of the files posted to the server by publishing via ClickOnce resulted in heavy traffic when dealing with frequent application updates, because binary files such as DLL's are not usually highly compressible. But note that MS states that ClickOnce deployment does use HTTP compression if enabled on the server
. So, if you're deploying ClickOnce applications via IIS, be sure to turn on HTTP compression (which will use GZip) on the server. HTTP compression is not enabled by default in IIS 6 but here's the procedure to enable and disable it
For one developer the accumulation of different versions of the software on server and clients' machines during frequent development updates due to the "side by side" model of ClickOnce mentioned above also resulted in file bloat on the clients' machines. His solution was to switch to using ClickOnce's publish-to-file-system option, then zip the generated files on his hard-drive, use FTP to put them up on his server where his clients could download them. You may wish to evaluate if using ClickOnce in a very frequent update situation, like beta-testing, is a good strategic choice.
While not everyone will run across the problems described so far, there is one generic problem that everyone may encounter, related to security certificates. If your certificate expires and you renew, ClickOnce subsequently treats your revised application as an entirely new deployment, possibly leaving your previous version physically present on the end-user's machines. Your end-users do need to uninstall and then re-install the entire application. This forum is a good source for other problems being reported from the field about ClickOnce and acknowledged by Microsoft.
At this time, I believe that ClickOnce is a fantastic "free" solution for the .NET 2.0 developer who wants to deliver simple classic desktop executables to end users via the Weband keep the application updated. It offers many interesting and compelling features out-of-the-box without having to mess around with other software tools.
I find it impressive that you can create ClickOnce installs that run from a hard drive, a Web server, an FTP site, or a CD! I'm planning to use it myself in its "must-be-online" mode to try and sell a client a prototype piece of software. If they don't buy my prototype, I'll pull the files off the serverand the application's gone.
If you are a small software house publishing an application with complex and frequently changing resource and data files, I believe ClickOnce is definitely something you should look into on a cost-benefit basis. Compare what ClickOnce offers to your current tools and their costs. You may find ClickOnce a valuable replacement for your existing deployment, install, update model.
If you are a network administrator with a lot of machines running mission-critical applications, many users requiring different downloads based on their security level and zones, tight needs for security and access control, and have a substantial investment in third-party tools used for updating, I think, at this point, you should at least explore ClickOnce, keeping it on your radar while following its evolution.
If your company has a deep mastery of Microsoft's MSI technology and of tools such as Mage and BootStrapper, then I think ClickOnce should be an immediate priority target in your ongoing search to improve the efficiency of the development and deployment aspects of your business.
If you have a heavy investment in COM components carried into your .NET apps (may the Gods help you !), and you want to use ClickOnce, you are also going to have to use "Registry Free COM" deployment (which should already be on your radar).
Finally, bear in mind that ClickOnce is merely a step along the progression from manual local installs to seamless automatic remote installation and update, but the evolution isn't over, as you can see by the problems listed in this article, and some of the information you can glean from the Helpful Links sidebar. You should expect to see future innovation in deployment, installation, and update technologies.