Question

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 Visual Studio 2005 (that is, .NET 2.0). I'm using Visual Studio 2008 now.

Was it helpful?

Solution

No, it is 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 its 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:

  1. Script the setup file to remove the version 1.0 installation automatically
  2. Script the setup file to launch the ClickOnce installation.

For subsequent updates, simply point the user to the "pure" ClickOnce setup package, and your updates should work fine.

OTHER TIPS

Make sure to test out your ClickOnce deployment very thoroughly in your client's environment. I am omitting details here, but there are many problems with ClickOnce. I have been supporting a ClickOnce application 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 Visual Studio 2005.

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 certificate expiration. Microsoft fixed this in .NET 3.5 SP1, but you had to dig through the release notes to find the comments that temporary or permanent certificates were no longer required. So - if you don't have a public CA certificate, and you'll be supporting this application 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 a custom step to auto-generate a file with the new assembly version.

The deployment project copies the version file to the output directory with MSI.

Each time the installed application runs, it compares its own version to the version in the version file in the deploy folder. If they differ, quit the application and launch the MSI, which we set to automatically remove older application versions.

This is a "poor man's ClickOnce" for an environment where there are no application deployment tools whatsoever avl (not even AD application advertising) so we made do. Again, this approach may not be sophisticated enough for you, but it works fine for us.

Best of luck.

The best way I know would be to send them an install program that:

  1. Uninstalls the current version
  2. Launches the ClickOnce application residing on the web.

With this, you'd have a reasonable upgrade experience, and from there out, ClickOnce can handle the upgrades on its own.

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 application have a default configuration file with a first-run flag of some sort that, when it gets to 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, and 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 application to use Clickonce where it didn't have that before.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top