One of the questions I see in the MSDN ClickOnce Forum is how to move a ClickOnce deployment to a different location. You might want to move your deployment because your company is setting up a new webserver, or because you change hosting companies for your deployment.
You can’t just change the URL because it’s part of the security built in to ClickOnce. It checks the update location for the installed application against the URL for the update, and if they don’t match, it won’t install the new version. This keeps someone from hijacking your deployment and substituting their own files.
This GoldMail will show you how to move your deployment to a different URL.
This download contains the source code (VS2008, C#) for the three versions of the application used in the GoldMail. If you are a VB developer and can’t figure out how to translate the code to VB, please post a comment and I’ll post a VB version of the code.
Click here to get the source code.
(edit) I couldn’t see how this could work with an Office Solution (VSTO), so I did some looking around. VSTO doesn’t use the update URL at all, so it looks like your customers have to uninstall and reinstall if you have to move a VSTO deployment. Dang.
Tags: ClickOnce
January 17, 2010 at 11:42 pm |
Very useful video Robin. Thank you for taking the time to document this!
January 18, 2010 at 11:29 am |
Thanks for the explanation – You made it look easy!
March 1, 2010 at 6:15 pm |
But…. What if you are no longer able to update server 1? Then your users are forced to uninstall / re-install? I’d like an option in the manifest that allows installation of updates from a different server. What about users who access a server by different names depending on if they are in the office or over a vpn? In all these situations, what if this is a “product” and not for internal development? I can’t change the manifest in these situations!
March 8, 2010 at 1:17 am |
If you can no longer update server1, then you do, indeed, have to have your users uninstall and reinstall. The deal is that the location of the deployment is part of the application identity, and is checked for security when checking for updates. This makes sure someone can’t hijack your user’s deployment and send him to another location to install files that are malicious.
I’m not sure what you mean by an option in the manifest allowing installation of updates from a different server. You can specify a URL for the updates in the Updates dialog in Visual Studio. That is part of how you move a deployment.
If you are deploying from a webserver, one thing you can do is use a DNS entry instead of the server address. For example, instead of http://www.myservername.com, use http://www.myapp.com where this is a DNS entry pointing to the same IP address as myservername.com.
If you could specify multiple update locations, how would the ClickOnce engine decide which one to get the update from? Just keep trying each one until it finds one it can actually use? This would increase the amount of time it takes to pull updates, unless the first address in the list was available.
May 26, 2010 at 2:46 pm |
Thanks! Just what I was looking for…
February 24, 2011 at 1:51 pm |
Nice.
May 9, 2011 at 3:51 pm |
Robin,
Thank you! This was a great explanation. Unfortunately, my new deployment server is a fileshare ////, rather than a webserver (http://). That means my users need to uninstall and reinstall. Right? I am developing on VS2010.
Old server: //aaaa/xyz
New server: //bbbb/xyz
May 24, 2011 at 9:35 pm |
This should work even if you are using a fileshare. Just put in the links to the fileshare instead of the web URL.
July 19, 2011 at 1:13 am |
Should this still Work in VS 2010 targetting 3.5? The steps seem straight forward, and I believe I have followed them carefully, but I am getting the following error which seems to explicitly state I cannot change the update location:
You cannot start application from location it is already installed from location . You can start it from location or you can uninstall it and reinstall it from location . If you reinstall the application, be aware that you might lose any customizations that you made to the application.
It looks like either MS plugged this helpful hole, or I am doing something wrong. Anyone else experience this problem?
July 19, 2011 at 9:26 am |
Yes, it should. In fact, our application is .NET 3.5, and it worked great for us.
July 21, 2011 at 5:37 am |
Thanks for the helpful video ant article. But in your example the machine where de deployments “live” is the same. In my case, we need to move from one machine to another and the ip’s and URL’s are completely diffrent. Also both machines are Apache servers.
When I publish to each of this servers independently, each works fine, updating versions ok.
But when I set the environment to move from server to the other (deploying that “bridge” version with the update URL pointing to the new server), I get an error related to the permissions. It is something like:
Subsets of RegEx are not permitted, unless both sets are identical.
I don’t have any idea what is happening. Is it a problem between servers or is it something related to the way the ClickOnce engine process the file xxx.appref-ms|
Thanks in advance for any idea.
July 21, 2011 at 11:00 am |
The example should work for moving from one server to another. I used it for my company to move our deployment from one CDN to another, with totally different URLs.
Be sure you set up the ClickOnce MIME types on the second server. This article lists them, and discusses apache specifically.
I’ve never seen that error before – “Subsets of RegEx are not permitted, unless both sets are identical.” When are you seeing this error? Is it when it’s trying to install it, or is it after it has finished installing it?
September 7, 2011 at 11:48 pm |
I think this is a server issue; I’ve never seen that kind of error in ClickOnce. If you’re still having a problem e-mail me, and I’ll ask the ClickOnce lead at Microsoft for his opinion.
July 22, 2011 at 1:27 am |
Hi Robin. Thanks a lot for your quick reply. I’m not sure if I have to answer by mail or reply in the blog. Anyway, I’ll send you this mail and feel free to put it in the blog or let me know how to proceed.
First of all, you’re right. I’ve tested each server indepently and the deployments works fine in each one; so the problem about MIME types is discarded (at less at first instance).
I’ll try to explain step by step what I am doing and what I get.
1.- Publish version 1.1 in server1 (update URL is empty) and required version=1.1
2.- Install that version from there and test it works fine.
3.- Deploy version 1.3 at server2 (update URL is empty) and required version=1.3
4.- Deploy version 1.2 at server1 (update URL is pointing to server2) and required version=1.2
5.- Start application at client machine. It checks for updates and it finds version 1.2 at server1, but at this point it finds out that the update URL for this version is at server2 and I suppose it try to download the version 1.3 from server2. It is at this point where I get the error at client machine, not being able to update.
Thanks a lot in advance for your interest and cooperation.
PD: I’ve sent you an email with log details.
September 7, 2011 at 11:47 pm |
I don’t know what to tell you; I’m pretty sure our CDN is unix-based, and this worked great for us. Why don’t you try setting the updateURL in version 1.3 to the same as the installation URL, just in case it’s looking at it? The other thing I would verify is that absolutely nothing else changed. If you changed the assembly name or the target CPU or something that is part of the deployment identity, this wouldn’t work. The ONLY thing you can change is the URLs.
August 17, 2011 at 2:42 am |
Hi again. I reviewed the configuration of Apache (not really me, but the people that manages it) and the problem persist. I don’t really have any idea of what is happening here.
I’ll appreciate a lot any suggestion.
Thanks in advance.
PD: Did you receive the mail with the details?
September 24, 2011 at 11:37 pm |
Very well explained indeed. Thanks a lot!
January 6, 2012 at 3:15 pm |
love it, it saved my bacon. Thank you.
January 9, 2012 at 7:18 am |
Great video – thanks! However, I have an issue…
I’m planning to move a couple of applications from the network share where they currently exist to our PDM system, in order to make them accessible to other departments. However, the PDM software we use (SolidWorks EPDM) works by creating a local view of the file archive on the user’s C:\ drive, and as such I’ll need the update path to be what looks like a local one.
Do you have any idea how I can get around this? From an organisational point of view, it makes most sense to try and push forwards with this approach somehow, rather than using a different network share. The only thing I’ve been able to come up with is using a symlink from the network path where the updates reside to this local path (which should be common to all users), but this seems like a messy solution…
February 12, 2012 at 7:30 pm |
I’m not sure I understand what the PDM software does. You say it “creates a local view of the file archive on the user’s c:\ drive” — create the local view where? Can you install software on the computer from a network share, or that IS the network share? Is it a mapped drive? Can you use a webserver? (You could put them in Azure blob storage for pretty minimal cost, for example).
If you need a local path as the installation folder, then set the installation URL to some path like C:\ClickOnce\ and copy the deployment over there, and then install it from there. Remember that the installation path must match the location of the deployment and also where the user will pick up updates.
February 20, 2012 at 2:48 am |
Sorry, there was a bit of ambiguity in my post. EPDM basically has a server with all versions of important files, and provides users with a “folder” on their C:\ drive which provides a view of the server’s contents, caching the desired versions of requested files. It’s not a mapped drive – just a local view of the archive server which is set up by the client software.
The reason that I’m wanting to use this is that it’s accessible to all the sites which would require use of my applications (also, I’m primarily a Mechanical Engineer rather than an IT Admin). I could use a webserver, but the one which is available for my use wouldn’t be accessible to one of the sites.
The problem with this approach is that I don’t believe that it’s possible to publish ClickOnce apps to local drives, since they’re intended for networked use.
February 15, 2012 at 8:48 am |
Hi Robin, (my savior)
My ClickOnce application suddenly started to fail during launch of the .application via Firefox/Chrome (online /offline application). after many investigation I realized that the tag:
under doesn’t exist anymore on the manifest and therefore when I try to run it from the “to be installed on” machine it searches for the application manifest on the local system, and obviously can’t find. I edited the manifset using the mage utility and problem solved.
my question to you is how can I cause VS to rewrite this tag? (I use VS 2010)
10x
Avi
February 16, 2012 at 4:39 am |
well, here is some partial solution:
it seems that the element has been removed since I didn’t use the project update feature.
I perform application updates manually so in order to still get the host name in the manifest I add it’s value to the “update location” field.