A few days ago I was doing a demo on ClickOnce and was asked a few questions that I felt others could benefit from. The first one was with respect to the folders/files generated by Visual Studio when you do deployments and the other one worth mentioning deals with desktop icons and Clickonce.
When I publish my application using VS 2005, it puts each deployment in a separate folder. In addition, it creates a [APPLICATION]_[VERSION].application file for each version. Moreover, there is a [APPLICATION].application file too. What is the reasoning behind all of this? Especially, the [APPLICATION]_[VERSION].application files?
When you publish an application using VS 2005, VS creates a deployment folder and names it based on your application name and version. The deployment folder contains everything about a particular version. VS also creates a deployment manifest based on the application and version (e.g., MyApp_1_0_0_0.application). Moreover, the firsttime you publish your application, VS creates deployment manifest (e.g., MyApp.application) that is independent of any version. The idea behind these files is to achieve server side rollback. The scenario is for you to do a deployment and send your users the link to the MyApp.application file. This deployment manifest refers to the latest version of the deployment. If you need to do a rollback on the server side for any reason, you can simply delete the MyApp.application and rename the latest version to MyApp.application.
Desktop Shortcut and ClickOnce
ClickOnce does not support the automatic creation of desktop shortcuts. Microsoft actually says that in their research they found that users don't like their desktop cluttered with icons and so they decided not to support desktop shortcuts with ClickOnce. If you have played around with ClickOnce to even a small degree then you know that ClickOnce also has an API that you can use to customize/supplement your ClickOnce deployment. If your users start asking for a desktop shortcut and you start to look for a way to achieve this, you'll likely end up using the APIs to figure out if the application is running for the firsttime (after a ClickOnce deployment) and if so, then execute some code that will determine the path to the application executable and then create a desktop shortcut. There are a few pitfalls that you have to consider before you jump into using desktop shortcuts with ClickOnce.
b) If your application does not have Full-Trust, then you might be eager to tell your users to just drag the Program Files shortcut for your application onto their desktop and then use that when launching the application. I highly recommend against this and here's why. Lets say you deploy version 1 of your application and a user drags the shortcut from Program Files onto the desktop. You then publish version 2 of your application. When the user goes to launch the application using the shortcut he created, he'll get a message that the application has an update and he will update and everything will be fine. The next day when he comes in and executes the shortcut again, he'll get a message that the application has an update and he will have to update again. This will continue, until there is version 3. When version 3 comes out, the ClickOnce runtime will delete version 1 (ClickOnce maintaines only 2 versions of an application per user). When the user executes the shortcut again, he'll get a message that the shortcut points to a file that doesn't exist. The bottom line is that when the user drags the shortcut to the desktop on version 1, you have no way of updating the target of the shortcut when an update happens--ClickOnce updates the shortcut when you do an update so everything works with the Program Files shortcut.
c) Another problem with desktop shortcuts is that you have no way of getting rid of them when your application is uninstalled.