Is it possible to introduce ClickOnce functionality to an existing application?
The scenario is: Version 1.0 is already installed on client premises. I would like to send them a new setup package which will upgrade to 1.1, which has ClickOnce functionality, thereby making future upgrades "effortless".
Barring that, are there any other solutions to this sort of problem?
p.s. The original application was developed with VS2005 (i.e. NET 2.0). I'm using VS2008 now.
No, not possible with a standard ClickOnce deployment scenario.
ClickOnce is a sandboxed installation on the client side. It will not know about Version 1.0 that's already installed. It is simply going to check to see whether it's GUID has already been installed via ClickOnce and if so update it, but only if the previous version was deployed via ClickOnce.
In your case if the user installed Version 1.1, both versions will be installed side by side. Version 1.0 will not be updated because ClickOnce doesn't know there's an association since it was deployed via a different method. If they don't want Version 1.0 anymore, they'll need to remove it manually. Once you've got Version 1.1 deployed via ClickOnce, subsequent updates will work correctly.
Don't think of ClickOnce as something you're "including", think of it as a method of deployment.
Alternatively:
I should clarify that what you're looking for is not possible with standard ClickOnce deployment. However, you mentioned you're going to send them an initial setup file. In that case you may have a workaround that's possible:
For subsequent updates, simply point the user to the "pure" ClickOnce setup package, and your updates should work fine.
I think in this case the "easiest" solution would be to just use the Clickonce deployment for the 1.1 version and as part of that new version of your app have a default config file with a first-run flag of some sort that when it gets run the first time by the user and sees that first-run flag, it looks for the previous version, copies over any existing configuration settings, then uninstalls the previous version automatically. It would require some programming on your part, but it's the solution I settled on at a previous job to do a similar task to upgrade a utility app to use Clickonce where it didn't have that before.
The best way I know would be to send them an install program that:
With this, you'd have a reasonable upgrade experience, and from there out, ClickOnce can handle the upgrades on its own.
A little late, but make sure to test out your ClickOnce deployment very thoroughly in your client's environment. Omitting detail here but there are many problems with ClickOnce. I have been supporting a ClickOnce app for 3.5 years now and have run into many problems with manifests, having to manually delete the sandbox storage folders so the updates install correctly, etc. - if you search online for ClickOnce problems you'll find quite a few issues in the MSDN forums and elsewhere, many of which MS does not appear to want to resolve as they've been open since VS2005.
Also, be aware of a potential gotcha in ClickOnce prior to .NET 3.5 SP1. If you do not have your own software deployment certificate from a CA recognized by the client machines, Visual Studio uses a "temporary" certificate (*.pfx) which expires one year from creation. After that time, subsequent update releases will probably not install, and will show users scary messages about cert expiration. Microsoft fixed this in .NET 3.5 SP1 but you had to dig through the release notes to find the comments that temp or perm certs were no longer required. So - if you don't have a public CA cert, and you'll be supporting this app for some time, then make sure you're on .NET 3.5 SP1.
Depending on the complexity of your scenario, since you ask about other solutions, we wound up using a "roll your own" approach that goes something like this.
Each updated release increments the assembly version as needed.
Build contains custom step to auto-generate a file with the new assembly version.
Deployment project copies version file to the output directory with MSI.
Each time the installed app runs, it compares its own version to the version in the version file in the deploy folder. If they differ, quit the app and launch the MSI, which we set to automatically remove older app versions.
This is a "poor man's ClickOnce" for an environment where there are no app deployment tools whatsoever avl. (not even AD app advertising) so we made do. Again, this approach may not be sophisticated enough for you, but it works fine for us.
Best of luck.