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: ClickOnce
RobinDotNet's Blog 
May 7, 2009 at 7:54 am |
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?
May 7, 2009 at 11:43 pm |
Thanks for your feedback, Sasha. I’m glad it’s helping someone. I’m sorry to say I haven’t played much with CAB apps and MSBuild. What I recommend is to post a question in the MSDN Forum for MSBuild which is here: http://social.msdn.microsoft.com/Forums/en-US/msbuild/threads
or the ClickOnce Forum which is here: http://social.msdn.microsoft.com/forums/en-US/winformssetup/threads/
I think MSBuild might be the better place, but if you don’t get an answer there, post to the CilckOnce forum.Thanks! –Robin
August 3, 2009 at 10:42 am |
Thanks for making this so simple. I also used your code for the desktop icon. GOOD WORK!
August 3, 2009 at 10:44 am |
Thanks! I’m glad it was helpful to you.
August 11, 2009 at 7:24 am |
Thanks a million! I’ve been trying to figure this out for a while. Your screencasts are WONDERFUL!
August 11, 2009 at 6:26 pm |
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. 🙂
September 20, 2009 at 5:17 pm |
Excellent, thanks.
September 22, 2009 at 7:39 pm |
Thanks! I’m glad you found it helpful.
March 9, 2010 at 3:34 am |
hi robin,
thanks.. this post helped me a lot.
March 9, 2010 at 3:52 am |
Cool; I’m glad you found it helpful!
March 9, 2010 at 4:02 am |
hi robin.
For concurrent installation, is it possible without changing assembly name?
any other way?
March 9, 2010 at 10:52 am |
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.
March 9, 2010 at 9:31 pm |
thanks robin.
March 10, 2010 at 3:25 pm |
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.
March 24, 2010 at 10:00 pm |
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.
June 4, 2010 at 9:48 pm |
this worked flawleslly, dont like the idea on changing the assembly but im ok with it.
June 9, 2010 at 8:25 pm |
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.
June 28, 2010 at 9:45 am |
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.
July 1, 2010 at 11:41 pm |
Thanks for your feedback. I’m glad you’re finding the blog helpful. At the bottom of the first page is a link for the RSS feed. It is https://robindotnet.wordpress.com/feed/
September 10, 2010 at 9:54 am |
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.
September 14, 2010 at 11:30 am |
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
September 14, 2010 at 1:20 pm |
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!
February 4, 2011 at 5:18 pm |
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.
February 6, 2011 at 3:21 pm
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
February 3, 2011 at 6:53 pm |
[…] 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 […]
March 16, 2011 at 8:04 am |
http://stackoverflow.com/questions/5316882/installing-a-click-once-application-from-two-different-locations
can anyone answer this for me?
March 23, 2011 at 1:04 am |
The answer is in this article on my blog. This is the blog entry used by the blog post you have referenced as your answer in the post on StackOverflow.
September 5, 2011 at 11:06 pm |
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
September 7, 2011 at 11:28 pm |
Thanks! I’m glad it was helpful.
January 31, 2012 at 9:43 am |
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
February 12, 2012 at 8:23 pm |
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
February 14, 2012 at 2:49 am |
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.
March 19, 2012 at 10:24 pm |
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
May 1, 2012 at 10:12 pm |
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
May 1, 2012 at 11:14 pm |
Thank robin for your reply,
We want to change it automatically. Is there anyway in clickonce to achieve it after installation.
May 1, 2012 at 11:22 pm |
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?
May 2, 2012 at 12:10 am
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
April 24, 2012 at 6:24 am |
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
February 18, 2013 at 4:53 am |
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?
February 24, 2013 at 2:43 pm |
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.
March 11, 2013 at 2:06 am |
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 …
April 6, 2013 at 4:56 pm |
Did you change the assembly name?
April 6, 2013 at 11:03 pm
Changing the assembly Name was the only thing that solved the problem …
August 5, 2013 at 9:41 am |
I tried everything here, but unfortunately, nothing worked. Did anyone encounter issues as well? I’m deploying a WPF application.
August 12, 2013 at 2:52 pm |
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
August 28, 2013 at 11:21 am |
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/
September 6, 2013 at 11:28 am |
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
September 11, 2013 at 2:27 am |
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.
March 6, 2014 at 10:30 pm |
[…] 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 […]
July 14, 2014 at 4:28 am |
does the application still check for automatic updates when i change the assembly name everytime?
July 14, 2014 at 4:10 pm |
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.
March 15, 2016 at 11:04 am |
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
May 1, 2016 at 11:59 am |
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
July 7, 2019 at 1:20 pm |
Worked perfectly for me. Thanks so much Robin, you are awesome!