How to move a ClickOnce deployment

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 video 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 video. 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.


57 Responses to “How to move a ClickOnce deployment”

  1. Tad Says:

    Very useful video Robin. Thank you for taking the time to document this!

  2. Vaxman2 Says:

    Thanks for the explanation – You made it look easy!

  3. J Davis Says:

    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!

    • robindotnet Says:

      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, use where this is a DNS entry pointing to the same IP address as

      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.

  4. Karsten Januszewski Says:

    Thanks! Just what I was looking for…

  5. Brian Duper Says:


  6. Dennis Wetherall Says:


    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

  7. Wesley Says:

    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?

  8. Pedro A. Peña Sanz Says:

    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.

    • robindotnet Says:

      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?

    • robindotnet Says:

      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.

  9. Pedro A. Peña Sanz Says:

    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.

    • robindotnet Says:

      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.

  10. Pedro A. Peña Sanz Says:

    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?

  11. Mauricio Leyzaola Says:

    Very well explained indeed. Thanks a lot!

  12. Daniel W. Says:

    love it, it saved my bacon. Thank you.

  13. Nick Stringer Says:

    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…

    • robindotnet Says:

      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.

      • Nick Stringer (@Nickedynick) Says:

        We’re using SolidWorks EPDM – it houses all our documents and CAD models on a server, and each PC with client software installed gets a folder on their C: drive which represents the working structure of said server. It’s integrated into Windows so that as far as the user (and PC) is concerned, every file on the server is actually in that folder. The software just stores a cached version of a file in this folder as and when it’s called for so that the entire server doesn’t need to be copied.

        I want to use this system to allow multiple sites access to my programs, since we don’t have any common regular network shares available to all groups.

        The problem I’ve had is that it seems that ClickOnce won’t let you specify a local path as a publishing location, so I’m unable to distribute through EPDM. I was just wondering if you’ve got any workarounds.

        • robindotnet Says:

          ClickOnce DOES let you specify a local path as the publishing file location. What you should do is have it distribute the deployment. For example, put it in C:\MyClickOnceApp\. If I’m understanding you correctly, then it will replicate that folder on the user’s machines.

          Try this — set the publishing file location to C:\MyClickOnceApp\ and leave the installation URL blank. If that won’t fly, then under Publish Options/Manifests, check “Exclude deployment provider URL.”. This is not a secure thing to do, but if you’re only installing in-house, you should be okay. What that does is remove the deployment provider URL, and then when the user clicks on the setup.exe from the C:\MyClickOnceApp\ folder, it sets the install location to that, and looks there for updates.

          Then (in theory), you should be able to put new versions in that directory (with the same file structure as if you published them to a web server), and their app should pick up the updates automatically.

          • Nick Stringer Says:

            Apologies, you’re entirely right! I must have gotten confused – I’m sure there was an issue with local paths not being allowed somewhere…

          • robindotnet Says:

            Nick, it doesn’t let you put a local path in for the installation URL. That’s what you’re thinking of. As noted above, you can get around that, you just have to publish it to the same path you’re going to copy it to on the user’s machine.

      • Nick Stringer Says:

        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.

  14. Avi Says:

    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)



    • Avi Says:

      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.

  15. Ashish Khatavkar Says:

    very nice.
    i want to add a database file with ext in publish wizard in 2008.
    please help me

    • robindotnet Says:

      I don’t know what “with ext” means. If you want to add a database, you need to add it to the project in Visual Studio. It will then be included in the deployment.

  16. Jason Rohde Says:

    Very usefull information! I do have some questions, though.

    If the developers are deploying to a URL, the sites are migrated to a new server, and then the DNS is changed to point the old URL at the new server, will ClickOnce automatically pick up the updates at the new server?

    • robindotnet Says:

      Yes, ClickOnce will automatically pick up the updates at the new server, as long as the installation URL is the same. It doesn’t care where the URL points to, so you should be okay.

  17. Brian Ushman Says:

    Hi Robin, I have seen so many great responses on here from you, wonderfully done!! I have a specific scenario I am trying to accomplish, can you let me know if this is even possible?

    I have a server app and a client app. I always want the users in an organization to have the client app at the same version of the server (because it’s dependent on the DB schema).

    So if the client has server app 1.0.5 installed. I will need to make sure that the user can still install a clickonce client app from revision 1.0.5 even though the clickonce server could be up to 1.0.7. I thought about the idea of publishing each revision to a seperate URL, however when it comes time to update the client app because a new server app was installed, I am not sure how to proceed. Since the update URL in the project settings was left blank, it will look at the install URL which will only have the current revision. Do you have any suggestions, or any ideas on taking this into a different direction? Hopefully everything I stated was clear.

    Thank you!

    • robindotnet Says:


      I don’t know of any way to do that in ClickOnce, other than for the user to skip the upgrade, which requires him to know what version it is, and what version server app he has. The deployment manifest in the top folder of the deployment folders defines what version the user should be running, and will determine what version the user will get if he installs it brand new.

      And of course if you put every version on a different URL, then the updates won’t work, and the user would have to uninstall and reinstall every time he wants to upgrade.

      Is the problem that the users don’t always have the most updated server application? Can you figure out a way for that app to always be up to date?


      • Brian Ushman Says:

        Thank you for your feedback Robin. You are correct, the server application may not always be up to date in which case I had wanted to allow a user who might have a server a few versions behind to install a matching client which would match that version and not have to upgrade the server each time. But it sounds like I will just have to always force an update on both server and client side. Thank you again for your feedback.

  18. Naama Says:

    Hi Robin,
    Thanks for the useful info! I’ve tried it, but encountered a strange issue, and I was wondering if you’ve seen this before.
    A little background: my application is installed locally, published it to a file share and set to look for updates before the application starts.
    After I publish the updates in both the old and new servers, my application gets the update, and it also copies the user.config, but it doesn’t merge it into the new version.
    BUT, if I restore back to the first version, and then update again (by clicking the .application file in the new location) – the application is updated, including the user.config file.
    This happens when I try two different update scenarios – by closing and reopening the application (to get the update through the application) and when I launch the application from the publish location.

    Have you ever seen this happen?

    Thanks in advance!

    • robindotnet Says:

      I’m not sure what “publish the updates in both the old and new servers” means. Are your customers accessing the deployment from different locations?

      I don’t use the Visual Studio configuration settings feature for storing settings that users can change. Here’s what I know about those settings: When the user installs a new version of the application, if none of the [identity] fields have changed, it copies the old user settings forward to the new deployment folders. If any of the [identity] fields have changed, including the signing certificate, it thinks it is a different deployment and won’t copy the settings forward. The whole thing is a little wonky, if you ask me. So I created my own class that writes a Configuration file in XML and stores it in Application data. This is then updated as the user changes his settings. If the user gets a new version, the file is not overwritten, and I specifically know where the file is and what’s in it. If the user has to uninstall and reinstall the application, he doesn’t lose his settings. This blog entry explains how (and why) I’m doing this.

  19. RT Says:

    Hi Robin,

    Probably a dumb question, but I would need access to the source code right? for COTS products, I’m out of luck with your method? Thanks in advance.


    • robindotnet Says:

      I don’t know what a COTS product is. This article is about moving a smart client deployment that is deployed using ClickOnce. Do you have that, or is it a different case?

      • RT Says:

        Hi Robin,

        Oh yeah, I was referring to a Commercial Off the Shelf product. I don’t have their source code so I can’t open it up in Visual Studio to edit the configurations. I saw some post about using mageui.exe to update the application file but I don’t have their security certificate so I can’t sign them. Any thoughts?


        • robindotnet Says:

          Do you have permission from the company to re-publish their application? Is their application already published with ClickOnce?

          • RT Says:

            Yes, I don’t have their permission explicitly but we are licensed, it is just that we have over 200 users on the app and I don’t really want to go uninstall from every one of those desktop. And yes, the application has already been published with CLickOnce. Thanks in advance for any suggestions.

        • robindotnet Says:

          If your COTS product is a ClickOnce deployment, you probably could take it and move it and re-sign it. You can change the URLs with Mage or MageUI. You *would* have to have your own signing certificate to sign the deployment, though. Not sure if it would work or not, but you could try it.

  20. Marc Says:

    Indeed a great article, but we also have an issue to move a ClickOnce deployment to a new server.
    We copyied the data to the new server and create in DNS the existing url as alias to the new servers ip address. So the url (file share) points to the new server.

    I then started the application on my client, it updated (strange because the new server has the same package) and it resulted in an error:
    Activation of … resulted in exception:
    System.Deployment.Application.DeploymentException (ComponentStore)
    Exception occurred during store operation. Value does not fall within the expected range

    After this we restored the DNS settings and created a new package on new server having the new server url links. To re-install the old server package I had to clear the C:\Users\\AppData\Local\Apps\2.0 folder. I re-installed from old server location and de-installed the application. Then I tried to install it from the new server location. The same error appeared.
    After again clearing the C:\Users\\AppData\Local\Apps\2.0 folder, I successfully installed from the new server location.

    Do you recognize this issue?
    I see the de-install clears some data from this 2.0 folder, but not everything.
    I also tried ‘mage -cc’, but this didn’t help.
    I guess we first should solve the de-install, before retrying the DNS change.
    Can you help?

    • robindotnet Says:

      If all you did was change the DNS entry to point to the new server, has anything about the URL changed at all, even the case? Is it in the exact same folder, etc? I will tell you that “value does not vall within the expected range” usually means a circular reference or you’re referencing two versions of the same assembly. ClickOnce caches common assemblies, so if you have two ClickOnce apps that use the same (strongly signed) assembly, it might have problems uninstalling or reinstalling one of the applications.

      To be honest, I’m surprised you had a problem. We moved one of our deployments by changing the DNS for our domain of our C/O app to point to a new IP address, and had no problem with it.

      • Marc Says:

        Thanks for your reply. I even didn’t expected this problem, because we had the same url and same folder. Maybe indeed something with caching.

        We now implemented the solution you already suggested in your GoldMail:
        1. Clients have installed version from old server
        2. I deployed version on new server
        3. I deployed version on old server having update path to new server
        4. Clients starts again the application and it automatically updates to version (from new server).
        This worked fine.

  21. Vince Says:

    Not sure if you’re still maintaining this blog, but my issue is application on server 1 updated to load application from server 2…like your video. Now I want to update and maintain the click once installs on the server 2. Problem is the application never get the new update…basically want to move the process of click once from server 1 to server 2. Seems to be a dead end.

    • robindotnet Says:

      I’m not sure I understand. If you follow the directions in the article, it should work. The old server has to still be available to pick up the update — is that the case? Did you deploy it as a required update, so the user can’t skip it?

      • Vince Says:

        The directions worked. Now I want to stop publishing to server 1 and start publishing to server 2. When I follow the directions in the article and then publish an update to the new server 2…it doesn’t recognize the update. So I’m suck with the initial version published to server 2. Does that make sense?

  22. Bart Thieme Says:

    I tried this with Visual studio 2012 with my unsigned application but got this error: “user has refused to grant required permissions to the application”. Is there a different method now or should it still work the same?

    • robindotnet Says:

      Where/when are you getting that error? This should still work. Is the user on Windows 8, and he’s not approving the application?

      • Bart Thieme Says:

        Thanks for the reply, but I have solved my problem by simply moving the application and performing a manual upgrade on both clients from the new location.

  23. Soum Says:

    The video doesn’t work. The message is “The requested PointAcross message does not exist.” Can you resolve it please?

    • robindotnet Says:

      The video should be working now. Sorry about that, the videos were hosted from the company I used to work for, and they disabled my account without telling me.

  24. Fedor Says:

    Video still doesn’t work, at least for me.

Leave a Reply

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

You are commenting using your 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


Get every new post delivered to your Inbox.

Join 71 other followers

%d bloggers like this: