I have several .NET Windows Forms applications that I'm preparing to convert into a ClickOnce/smart-client deployment scenario. I've read the isn't-this-great tutorials, but are there pitfalls or "gotchas" that I should be aware of?
There are several minor applications used off and on, but the main application is in C#, runs 24/7, is quite large, but only changes every few weeks. It also writes to a log file locallly and talks to local hardware devices.
I didn't know that SP1 allowed you to create the desktop icon.
Here's how we have been doing it (now known as "the hard way"):
There are a whole lot of things you can't do with ClickOnce applications, like install a shortcut to the user's desktop or have any sayso in where the application gets installed. For some people these are dealbreakers.
Also it's been a while since I used it, but there's a special way you can use to figure out and display the ClickOnce version/build number, which is separate from the application's version/build number. You have to do a try/catch and if the ClickOnce version/build number throws an exception then the application is not running as a ClickOnce-deployed application (that is, it's running as a regularly compiled application or from Visual Studio).
For an application which is simple (that is, not Microsoft Word, but rather a quick-and-dirty application to do something) and needs a lot of regular deployment, ClickOnce is great. But you rather quickly hit the wall of "oh, this can't be done by ClickOnce, please choose MSI or something else).
You'll have less system access than your normal .NET application.
That's because you'll get a lower trust level. More about that in .NET Framework Developer's Guide: ClickOnce Deployment and Security.
My biggest problem with that was that it's not possible to encrypt sections of your configuration file with the machine key, because you don't have the access to that key (when you think about it it makes sense to protect that key).
Most issues have been addressed but several people mentioned not being able to create a desktop shortcut. In fact, you can create a desktop shortcut with Visual Studio 2008 SP1.
Also, if you aren't using the latest version of Visual Studio, you can always write code to create a shortcut to the installed start menu shortcut.
We had an app we were going to deploy as a ClickOnce app. We needed the user to be able to modify some settings in the installation (such as the deployment path - IT wants to serve the files from their network share, not known at build time). When you change any of the files in your deployment, you need to re-calculate all of the hashes, and re-sign everything. So, if this solution is internal, you may not have problems passing around a signing cert, but if this is for clients, you will need to architect a fancy solution to bypass this issue.
I have heard rumblings from somewhere within the bowels of the internets that a future version of ClickOnce will remove some of this headache.