ClickOnce: Concurrent versions

One of the questions that comes up a lot in the MSDN ClickOnce forum is how to deploy an application so the user can install multiple versions of it, like a QA version and a production version. Basically , you have to change the assembly name and the product name. This GoldMail illustrates how to do this, and mentions a couple of other considerations as well.

Tags:

53 Responses to “ClickOnce: Concurrent versions”

  1. Sasha Says:

    Hey Robin,

    Thanks for the ClickOnce goldmails! Would you have a minute to answer a ClickOnce question? Thanks!

    I am trying to build ClickOnce off a folder with an already built WinForms application. It is CAB based application, so referencing dlls is not straightforward.

    Do you know of an example script that I can use to help me with the task?

    Here is what I have so far:
    – Copying correct application and config files into a temp folder.
    – Using GenerateApplicationManifest and GenerateDeploymentManifest in my MSBuild file. This step seems to work, but the relative pathing in application manifest gets screwed up for some reason.

    Could you recommend a link to anything that would address this scenario?

  2. Chuck Says:

    Thanks for making this so simple. I also used your code for the desktop icon. GOOD WORK!

  3. Tim Says:

    Thanks a million! I’ve been trying to figure this out for a while. Your screencasts are WONDERFUL!

    • robindotnet Says:

      Thanks, I’m glad it was helpful! My “screencasts” are GoldMails — audio slideshow messages — that you make with pictures, PowerPoints, regular text slides, screen captures, etc, and then record your voice over them. It’s fun and inexpensive to use. I’m DoE for them, and have really enjoyed actually using the product that I work on! If you’re interested, you can try it free for 30 days at http://www.goldmail.com. 🙂

  4. John B Says:

    Excellent, thanks.

  5. tushar Says:

    hi robin,

    thanks.. this post helped me a lot.

  6. tushar Says:

    hi robin.

    For concurrent installation, is it possible without changing assembly name?

    any other way?

    • robindotnet Says:

      Nope. The assembly name is used for the foldering and identity by the ClickOnce deployment. If you don’t change it, it won’t appear as a different application. In fact, technically, that’s *all* you have to change. Changing the info on the start menu is just common sense, but not required.

  7. psamagal Says:

    Hi robin, thanks. It helped me a lot.
    It’s possible pass parameters to a clickonce deploy? In the case pass different ones for each different version installed (The application is a off-line application). The objective here is run multiple versions of the same application (production, development, qa) in the same computer in each every instance will receive a different parameter indicating the location of the correspondent database.

    • robindotnet Says:

      Yes, it is possible to call a ClickOnce deployment with arguments. I’ve added a blog posting here that shows both calling and receiving the arguments. Hope it’s helpful to you.

  8. Oscar Says:

    this worked flawleslly, dont like the idea on changing the assembly but im ok with it.

    • robindotnet Says:

      Thanks, it’s an easy way to accomplish the goal of running concurrent versions! I read somewhere else that you can just change the deployment name, which involves publishing to a folder, changing the name of the deployment manifest (.application file), editing it with MageUI and changing the value inside, and re-signing it and so on. I tried it out and found that it was not only a pain in the you-know-where, but it didn’t work as cleanly as just changing the assembly and product name.

  9. joe Says:

    Thank you for this fantastic information because finding relevant sites on this topic is sometimes hard to find. You did an excellent job covering the subject and I look forward to more posts from your site. Do you offer RSS Feeds or feedburner to get more content for our blogs? I will be sure to include links from my other blogs to yours.

  10. luis Says:

    Hi Robin,

    I tried your advice by publishing two versions of an excel template solution to different folders in a share drive. I also took care of changing the assembly name. Unfortunately it doesn’t seem to be working for me. What I see is that the code that runs is coming from the last solution that was installed. If you have any insights on things I can try to troubleshoot this issue, I will greatly appreciate it. Thanks.

    • luis Says:

      Hi Robin,

      I figured it out and now I can publish two versions of the same solution to the SAME location.
      I had to do the following:
      1. Change the Assembly Name (and product name)
      2. Change the template name
      3. (This was the key step) Change the Solution Id. To do this I had to
      3.1 Unload the project from Visual Studio
      3.2 Use the GUID tool in visual studio to generate a new GUID
      3.3 Edit the project file in Notepad and change the solution Id GUID to the new GUID created.
      3.4 Reload The project in VS
      4. Publish.

      Since the assemblies, vsto files and application files folders have different names it really doesnt matter that they get published to the same location.

      I just thought to post this here in case someone else was having the same issue.

      Thanks

      Luis

      • robindotnet Says:

        Thanks Luis, for posting back the answer. I’m sure others will come along looking for help and appreciate that you’ve shared your solution!

        • Peter Kellner Says:

          Hi Robin,
          Is Luis’s suggestion necessary to make this work? Is this what you do in goldmail to have an internal version running? It seems like yours would not work if this step was really necessary. Any thoughts would be appreciated and of course, thanks for posting such a nice video for how to create multiple installations.

          • robindotnet Says:

            Hi Peter,

            Thank you for your feedback. At GoldMail, I can simply change (a) the assembly name, (b) the product name in the project properties, and (c) the deployment URL and it works. I do occasionally make additional unrequired changes such as the caption on the application, the log4net config file (so the logging goes into a separate file) and if it’s a long-term beta, I might change the application icon. We frequently run multiple versions of both our desktop product AND our Office add-ins concurrently for testing purposes. At one point I had 3 or 4 different versions installed.

            For Luis, I don’t know why he had to go to so much trouble to get it to work. The only thing I can think of is he’s doing document-level VSTO add-ins (he mentioned Excel and templates), which I haven’t had an opportunity to publish. I’d still be surprised if it took that much effort, but since I haven’t tried it, I can’t say for sure that it wouldn’t.

            Robin

  11. ClickOnce Deployment - Deploying multiple versions of the same application | Helpless Automation Says:

    […] above instructions were referenced from this blog post by RobinDotNet. She has included a Screen Cast if you would like to check it out. Have fun with […]

  12. coder Says:

    http://stackoverflow.com/questions/5316882/installing-a-click-once-application-from-two-different-locations

    can anyone answer this for me?

  13. single dating of Deutschland Says:

    Thank you for every other informative website. Where else could I am getting that type of information written in such an ideal way? I have a project that I’m simply now running on, and I’ve been on the glance out for such information.king Regards Hugo

  14. Avi Says:

    Hi Robin,
    not exactly this post issue but related somehow, I need to be able to install my clickonce app from two different deployment locations – a web url and/or local file system path.
    the problem is that if I install it one way and then try to run it from another location I get an error:
    ERROR SUMMARY
    Below is a summary of the errors, details of these errors are listed later in the log.
    * Activation of http://MyServer/MyApp/MyApp.application resulted in exception. Following failure messages were detected:
    + You cannot start application MyApp from this location because it is already installed from a different location.
    + You cannot start application MyApp from location http://MyServer/MyApp/MyApp.application it is already installed from location file:///D:/deploy/MyApp.application. You can start it from location file:///D:/deploy/MyApp.application or you can uninstall it and reinstall it from location http://MyServer/MyApp/MyApp.application. If you reinstall the application, be aware that you might lose any customizations that you made to the application.

    any way around this other than suggested?

    regardless this question you have been very helpful and your posts are great 🙂

    Thanks,
    Avi

    • robindotnet Says:

      Hi Avi,
      You can’t access an application from two different url’s. The installation URL is part of the identity of the deployment, and if you install the app from one and try to install from another with a newer version, it will fail (as you have discovered). This is a security issue, to help ensure that someone doesn’t highjack your deployment and replace it with their own.

      Why do you need to do this? What are you trying to accomplish?

      Robin

      • Avi Says:

        I’m trying to accomplish the ability to deploy the application via web and local system (but still keep all clickonce capabilities), but we have discussed the solution in another post, what I do is put the deployment output both on the web server and the local system (using an installer) since it seems that even if you set the deployment output on VS to a web server you can still place the output files on a local machine and run it from there while behavior is the same.

  15. Tushar Says:

    hi robin,

    Is it possible to change Product Name of a already installed clickonce app?

    We want to change name in start menu and short cut.

    Thanks

    • robindotnet Says:

      You should be able to change the product name. The only thing it is used for is to set the name of the application on the start menu. If you change the assembly name however, you will have to uninstall and reinstall, because that is part of the identity of the deployment.
      Robin

      • riken Says:

        Thank robin for your reply,

        We want to change it automatically. Is there anyway in clickonce to achieve it after installation.

        • robindotnet Says:

          You mean you have an installed application, and want to change the product name? There’s no way to do this that I know of (unless you want to just rename the name on the shortcut in the start menu). You can’t just publish an update with a new product name?

          • riken Says:

            Thanks Robin,

            Actually requirement is like:

            we have one clickonce setup which can work as product1 and product2 based on one flag.

            Now if user wants to switch from product1 to product2 then he/she does not need to install product again as one setup can work as both product based on just one flag.

            In this case we just want to change product name automatically in start menu and on desktop shortcut.

            Is it possible?

            Riken

  16. James Says:

    Robin,

    Many thanks for providing such high quality information and concise delivery with the screencast. I was battling a nagging installation issue which had defeated several strategies I found elsewhere on the web. I was able to quickly resolve it by leveraging some of the information found here. Your blog is now on my list of required reading!

    – James

  17. Prasad Says:

    I am facing an issue with the above approach. I need to install multiple versions of my application. The problem with changing assembly name as mentioned in the above approach is that my project has references to the images using packed URI format : e.g Source=”\AssemblyName;Component\Images\img1.jpeg” . So changing the assembly name is not feasible everytime. Can you suggest me a better approach?

    • robindotnet Says:

      The only other way to do it is to change the name of the deployment manifest and application manifest after you’ve published, and then re-sign them. I think if you do this, you can publish with the deployment name not matching the assembly name, and all of the directories, etc., will be tied to the new name rather than the name of the assembly. You would have to try it to find out.

      • tokra Says:

        I’m facing the same problem Prasad does.
        So I tried the following:
        Compiled my application (“myapp”) in DEBUG mode and publish it to Location A, then compiled the app in RELEASE-Mode and publish it (with the same version number) to Location B.
        Installed the app from Location A and when I tried to install it from Location B, ClickOnce tells me that I can’t install the app because it is allready installed on another place.
        So I opened the myapp.exe.manifest using mage.exe located in the target location B in “Application Files/MyApp_Version” and changed the name from myapp to myappRELEASE.
        Then I opened the .application file created by the ClickOnce-Deployment and referenced the manifest file there.

        If I now try to launch the application using the .application file in the root-path it tells me:
        an application for this deployment is already installed with a different application identity

        But if i select the .application file in “Application files/MyApp_Version” folder I’m able to install and launch the application and I’m able to launch DEBUG and RELEASE side by side.

        Yes … happy!

        But then, frustration strikes back:
        I updated the application in DEBUG and deployed a newer version to LOCATION A (Debug) tried to launch it and it tells me, that the application is allready installed at another place …

        Resignation …

  18. Arnold Says:

    I tried everything here, but unfortunately, nothing worked. Did anyone encounter issues as well? I’m deploying a WPF application.

    • robindotnet Says:

      You must be doing something different, because this has worked for every application I’ve tried it with, including client apps and VSTO apps. Please post a question to the ClickOnce forum and post the link back here and I will look at what you are doing.
      Robin

  19. todd_beaulieu@yahoo.com Says:

    You most definitely DO NOT have to change the assembly name to get side by side. What controls the identity of the application is the APPLICATION MANIFEST, not the assembly. VS doesn’t let you control the manifest identity, but MSBUILD does. I have a team build in place that builds dev/qa/prod packages (build+deploy actions) at the same time. I then promote them as needed via TFS deployer. It’s been a very long time since I looked at this stuff, which is why I’m revisiting it today. I need a quick fix to do this manually because I don’t want to carry forward that custom build from 2008 into 2012. The piece that you’re missing is the certificate. When you sign a package that signature is part of the unique identity of the application. By having three certificates (home grown) you can deploy it three times with three certs and all will live in harmony.

    http://toddbeaulieu.wordpress.com/2009/04/20/generating-multiple-click-once-packages-from-team-build/

    • robindotnet Says:

      Thank you for your feedback. I agree that it’s not a 100% requirement, but it’s the easiest way to go for most people. There’s an identity field in the deployment manifest that you can change, and then it will show up as a separate deployment with the same assembly. For most people, this is too complicated, and simply changing the assembly meets their needs. Thanks for posting the link, in case that’s helpful to someone else.

      Robin

  20. Riken Says:

    Hi All,

    We are facing two issues related to concurrent clickonce installation.

    1) We have two version of our application, Production and Beta. We use different assembly name so that we can install and use both simultaneously and it works accordingly. But problem come when we uninstall one of them. Uninstall either simply removes only from Control Panel’s Program list but not from clickonce installation folder. Due to this we cant install a product which we have uninstalled(not really) and gives error like “Application with same identity already exists”. My observation is this problem happens almost every time if I uninstall any one application while another is running, but it happens few times if we make sure that both of them are not running while we uninstall any one of them.

    2) Sometime our application installation gives error if user has some other clickonce app installed before our application. In this case only solution is to clean whole clickonce folder but this removes already installed applications.

    Did any one face any/both of above issue and any suggestion\solution for the same?

    I put these same issues here before couple of days but from today morning it is just gone away and so putting it again so that someone can help me and others having these issues.

  21. Generating multiple versions of ClickOnce applications with Team Build — ALM Guide - Esteban Garcia Says:

    […] are plenty of resources on the web that show you how to do this manually (for example, this one: https://robindotnet.wordpress.com/2009/04/22/clickonce-installing-multiple-versions-concurrently/).  Basically, you have to change the assembly name and the product name.  But what if you need to […]

  22. Thxer Says:

    does the application still check for automatic updates when i change the assembly name everytime?

    • robindotnet Says:

      The assembly name is part of the application identity. If you change it, ClickOnce will have no way of knowing it is the same application, and it will be treated as a separate application altogether.

  23. Kenneth E Fannon Says:

    Hi Robin,

    This is an excellent post about concurrent installations.

    My problem is similar but different. I have a ClickOnce application that I need to deploy to multiple sites (plants). Everything I have read says that a single deployment copied over to different locations will not suffice, because of the signature embedded within the deployment. I’ve also read about various workarounds.

    We are using VS2013 WinForms to develop this application; it is currently in the dev/testing phase and not ready for true deployment. With that said, I have a similar application what was originally deployed using Windows Installer (VS2008) and InstallShield (VS2013), that I am converting to a ClickOnce system.

    Our organizational setup:

    Each plant has its own share on the network (//Organization/SharedData/Location/). Likewise, each user also has a personal share)
    When a user logs in to the system, the user’s drives are mapped such that F: is mapped to (//Organization/UserData/Location/UserName), and G: is mapped to (//Organization/SharedData/Location).

    The intent is to deploy the application such that whenever a user needs the application, they will go to [G:\Schedule\Distribution\Application] and run setup.exe.

    The real question is – why could we not deploy to one share, copy to the other shares, and simply use the URI (file:///G|Schedule/Distribution/Application) as its install and/or update location?

    Is there a better solution for this? Our primary objective is increasing time spent developing and improving applications, whilst reducing time consumed in the deployment process (manually deploying to each server or installing on individual computers is extremely troublesome, especially when there are at least twenty sites, with at least 100 PCs per site to contend with).

    If you could advise or point me in the right direction, it would be greatly appreciated.

    Thanks!!

    Kenneth E Fannon

    • robindotnet Says:

      You can put the files on one share and have everybody access it from there. If you want to put it on different shares per organization, you can do that, but you will probably have to publish multiple versions. You can try leaving the installation URL blank and the update URL, and have them install it from a share that they access, and it might pick up that location and store it as the deployment location. Not sure if that will work. Also note that if they all mount their shares with the same drive letter, you can totally set the installation as R:\ourapps\ClickOnce\whatever and they will all pick it up from their own versions of the ‘R’ drive. This is probably going to be the easiest way for you. You can publish once, distribute, and it should just work.
      Robin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: