I have multiple versions of a clickonce application deployed on a tomcat server (e.g)
and myApp_2_0_0 (a development beta)

How do I allow a user to select which version of the application to start?

If for example I want to launch the old version, I navigate to http://myserver/myApp_1_1_0.application. This doesn't work and newest version of the application is loaded.

The only solution I have found is to dynamically replace the content of the application directory. This is not a viable solution as there will be many concurrent users.

I am able to store the version of the application they *want* to run in a database, so could use some code on the server to interpret the update request and force a redirect, but have no idea how this can be done.

One possible solution (at least for the development/stable release switch) would be to release the development application with a different name or key so it is a different application as far as the running machine is concerned. This wouldn't help me support running of the old builds.

The default behaviour should be the usual dynamic updates of the current release, but I need to offer my users the opportunity to run an old or development release.

Is this a common challenge? Is there an easy solution I have overlooked? I do not mind if the user is left with a single version on their machine which changes based on selection they make on the publish page or if they have multiple versions installed.

Any ideas would be welcomed.


N

The answer to your last question is No.

If you are using VS2008, the deployments are under that root folder of the publishing location in "Application Files". There is a folder under there for each version, and each one has a yourapp.Application file.

If you are using VS2005, the application files are in the root folder of the publishing location, and have the version number in the name.

You can try linking to those specific application files, but I don't know if it will work.

You can not rely on the folder structure of those folders being the same. As I've noted, it has already changed between VS2005 and VS2008. The intention of ClickOnce is for VS to create the manifests and internally they know where the deployment folder it, and there's nothing you can do about that.

If I *had* to do what your users want, I would set up a separate url for each version, and limit the number of versions back that a user can go. What if you have structural changes to your database, or something like that? Also, there's no guarantee that the user won't pick up the newest version as an update after installing the old version. That is the POINT of ClickOnce -- to keep users up-to-date, not to have them be able to run any version. In order to split the versions apart, you would need to deploy them to separate locations.

The other thing to consider is you need to have your users uninstall the version they are running before installing the next one. Our QA people jump from the public build to the QA build to another QA build and back to the public build, and we had problems with it, and it sometimes completely messed up their deployment folders, and we had a couple of cases where it showed our application installed in the Control Panel but it's not even on the machine any more.So I asked them to be sure to deinstall the current version before installing a new one from a different build/url, and that took care of the issue.

ClickOnce is not designed to do what you are trying to do. You might want to consider using a Windows Installer package instead. Kludging up the ClickOnce stuff may bite you in the a** in the future. Of course, it's free to try it, isn't it?

Good luck.

RobinS.

GoldMail.com

You can't do exactly what you are trying to do, because you can't rely on the folder structure staying the same. For example, it changed between VS2005 and VS2008.

The only way to force the installation of an earlier version is to copy that version's .application file to the top level and replace myapp.application. This is not a recommended practice unless you are backing out a bad version.

You can have multiple deployments, and your users can have multiple versions installed, if you deploy from different url's. To deploy the same application multiple times, change the assembly name under the Application tab for the main project. I'd also change the Product Name under the Options, because that is what shows up in the start menu.

I think you need to figure out exactly what your goal is. Do you need to be able to go back one version? Do you need to be able to deploy multiple versions simultaneously? What exactly does the user really need to be able to run?

We havea handful of url's that we use. We have two for QA testing for when we have two releases in the works. We also have one for the public, and I have two that I personally use to deploy versions for specific people to try out new features. This is the safest method, because we know what each of the url's is used for, and are unlikely to mess up anyone using one of them, like if we backed up one version for one of the QA branches, and someone was testing that version.

RobinS.

GoldMail.com

I'm also trying to select a specific application version to run.

My goal is to guarantee client/server compatibility while providing automatic updates for the client and the server.

I was wondering if this would be possible using clickonce parameters and a distant web service handling .application files.

The answer to your last question is No.

If you are using VS2008, the deployments are under that root folder of the publishing location in "Application Files". There is a folder under there for each version, and each one has a yourapp.Application file.

If you are using VS2005, the application files are in the root folder of the publishing location, and have the version number in the name.

You can try linking to those specific application files, but I don't know if it will work.

You can not rely on the folder structure of those folders being the same. As I've noted, it has already changed between VS2005 and VS2008. The intention of ClickOnce is for VS to create the manifests and internally they know where the deployment folder it, and there's nothing you can do about that.

If I *had* to do what your users want, I would set up a separate url for each version, and limit the number of versions back that a user can go. What if you have structural changes to your database, or something like that? Also, there's no guarantee that the user won't pick up the newest version as an update after installing the old version. That is the POINT of ClickOnce -- to keep users up-to-date, not to have them be able to run any version. In order to split the versions apart, you would need to deploy them to separate locations.

The other thing to consider is you need to have your users uninstall the version they are running before installing the next one. Our QA people jump from the public build to the QA build to another QA build and back to the public build, and we had problems with it, and it sometimes completely messed up their deployment folders, and we had a couple of cases where it showed our application installed in the Control Panel but it's not even on the machine any more.So I asked them to be sure to deinstall the current version before installing a new one from a different build/url, and that took care of the issue.

ClickOnce is not designed to do what you are trying to do. You might want to consider using a Windows Installer package instead. Kludging up the ClickOnce stuff may bite you in the a** in the future. Of course, it's free to try it, isn't it?

Good luck.

RobinS.

GoldMail.com