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.
Tags: ClickOnce
RobinDotNet's Blog 
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 16, 2012 at 11:16 am |
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.
March 8, 2012 at 12:44 pm |
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.
March 9, 2012 at 6:08 am
Apologies, you’re entirely right! I must have gotten confused – I’m sure there was an issue with local paths not being allowed somewhere…
March 9, 2012 at 10:24 am
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.
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.
March 5, 2012 at 8:11 am |
very nice.
i want to add a database file with ext in publish wizard in vb.net 2008.
please help me
March 8, 2012 at 12:38 pm |
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.
May 15, 2012 at 7:02 am |
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?
May 15, 2012 at 9:41 am |
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.
May 31, 2012 at 2:24 pm |
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!
June 1, 2012 at 8:56 am |
Hi,
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?
RobinDotNet
June 5, 2012 at 7:04 am |
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.
June 5, 2012 at 9:58 am |
No problem. Good luck!
June 3, 2012 at 8:25 am |
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!
Naama
June 28, 2012 at 1:38 am |
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.
July 26, 2012 at 5:25 pm |
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.
cheers,
July 27, 2012 at 2:47 pm |
Hi,
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?
Robin
July 27, 2012 at 3:41 pm |
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?
cheers
July 28, 2012 at 1:21 pm |
Do you have permission from the company to re-publish their application? Is their application already published with ClickOnce?
July 30, 2012 at 9:37 am
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.
October 8, 2012 at 9:31 pm |
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.
August 14, 2012 at 3:03 am |
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?
October 8, 2012 at 10:09 pm |
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.
October 8, 2012 at 11:04 pm |
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 3.3.2.2 from old server
2. I deployed version 3.3.2.4 on new server
3. I deployed version 3.3.2.3 on old server having update path to new server
4. Clients starts again the application and it automatically updates to 3.3.2.4 version (from new server).
This worked fine.
October 8, 2012 at 11:06 pm |
I’m glad it worked for you. Thanks for reporting back.
June 6, 2013 at 8:10 am |
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.
June 6, 2013 at 9:24 am |
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?
June 6, 2013 at 11:59 am |
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?
September 23, 2013 at 6:45 am |
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?
April 11, 2014 at 3:09 pm |
Where/when are you getting that error? This should still work. Is the user on Windows 8, and he’s not approving the application?
April 14, 2014 at 12:44 am |
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.
May 7, 2014 at 8:38 pm |
The video doesn’t work. The message is “The requested PointAcross message does not exist.” Can you resolve it please?
June 18, 2014 at 10:34 am |
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.
August 12, 2014 at 12:23 am |
Video still doesn’t work, at least for me.
August 12, 2014 at 3:14 pm |
I don’t know what to tell you. It works for me. I’m using IE11, if that helps at all.
May 1, 2015 at 11:17 pm |
Hi Robin,
Great post but I’m having some problems getting this to work.
My app is published to a server file share \\server\share\folder.
It installs and updates fine but i wanted to test moving it to another location.
I followed your instructions but the app just updates to the intermediate version in the original location and doesn’t pickup the new url.
I am changing the assembly and file versions each time, could that cause issues?
Also the new location is just another folder on the same server and has a space in it.
Any ideas?
Rick
June 30, 2015 at 6:58 pm |
Go through the instructions and try it again. I tested this using file shares as well as URLs, and it worked fine. And you *want* to change the version each time. I’m assuming you’re incrementing it. And just for grins, try it with a folder without a space in it. Stick an underscore in there and see if that helps.
Robin
May 18, 2015 at 5:04 am |
videos are nice and all … but a quick text summary (even without screenshots) would be awesome for those of us with short memories – to refresh what we had to do last time. 🙂
June 29, 2015 at 4:44 am |
[…] know that I can change the installation URL path using this technique, but is it also possible to change the application name? Ideally I would like to uninstall the old […]
June 30, 2015 at 6:55 pm |
Sorry, you can’t change the application name this way. It is part of the unique fields that make up the deployment’s identity. It won’t pick up the new version from the file if the application name is different.
I had a case where I was trying to do this, and I wrote a small console app that would uninstall the current application and then call to install the new one. That would totally work for you.
July 22, 2015 at 3:08 pm |
Great tutorial, you wouldn’t happen to have a copy of the source code from the old msdn link originally provided? Source is no longer available on msdn
August 9, 2016 at 9:48 am |
Dang it, I don’t have a copy of that code, and you’re right, the URL is dead. I don’t remember there being any code around it, just how the URLs are set. If I run across the code, I’ll post the URL here.
August 11, 2015 at 8:15 am |
Hi robindotnet,
Learn a lot from this video, thank you.
I have a question, if I put the version v1.3 on both TESTURL 1 and TESTURL 2 directly, what is the matter?
v1.1 will check for update on TESTURL1, and find v1.3 directly.
Now on Win 7 and Xp, this method works, but not on Win 8, could you please point out the reason?
August 19, 2015 at 12:58 pm |
There is no reason it would work on windows 7 but not work on windows 8. Have you tried enabling the enhanced logging to see what’s really going on?
August 26, 2015 at 10:24 am |
Hi robindotnet,
I mean I did not put v1.2 on either TESTURL1 or TESTURL2, on windows 8 or 10, it will be failed with message “user has refused to grant the permission for this application”. I think the security setting on windows 8 or 10 are different from Windows 7.
August 9, 2016 at 9:35 am |
As noted in the articles about Windows 8 (which also apply to windows 10), I noted that the customer is going to be prompted by the smart screen filter. They have to actually click something like “install anyway” or “more info” to override that filter.
Robin
August 24, 2015 at 10:21 pm |
hi Robin,
Yes, this no longer works for my apps, something has changed, using VS2013 NET 4. I made test sites called TestClick and TestClick1 using your example.
Error message when trying to move from TestClick to TestClick1:
You cannot start application TestClickOnceWpfApplication1 from location http…./TestClick1/TestClickOnceWpfApplication1.application it is already installed from location http… /TestClick/TestClickOnceWpfApplication1.application.
Used to always work some time ago, now fails.
August 24, 2015 at 11:41 pm |
I got the answer to my problem: Initially the update location must be blank for the version to be moved, when it is first published, as you did in your V1.1. I have been setting it to the same as the publish location, thinking that would have no effect. Not sure where this is stored, could not find it in manifest, but it does block moving the app to the new location later.
Also I think you need to make sure the Option “Exclude deployment url” is not checked too. Hope this helps others.
August 9, 2016 at 9:40 am |
You don’t have to exclude the deployment URL. When the user has the app installed, if the update URL filled in, it will go there for the update instead of to the original deployment URL.
August 9, 2016 at 9:38 am |
It looks like those are two different applications. The application name is part of the security of ClickOnce; if you change it, it does not recognize it as the same deployment.
November 26, 2015 at 5:29 pm |
Wonderful – Thanks a lot Robin. You really helped me out here 🙂
Best regards,
Ægir
January 9, 2016 at 6:41 pm |
Hi, will this work if I were to publish 1.2 (as from your example) without publishing 1.3 previously? The idea is to publish a version that will simply look for *future* updates at a new location which currently has no updates. I need to keep the old server around until all users are updated anyway, so there really is no rush to move to the new one immediately.
May 1, 2016 at 12:05 pm |
It won’t work. You have to have the new version available. Note that you can take the old version and increase the version number using mage or mage ui, re-sign the manifests, and put them on the new server. So it looks like a new version and will install, but nothing has really changed. Otherwise, just don’t do the move until you’re really ready.
April 9, 2016 at 9:43 am |
hello,
can you publish the same project from different computers and different users?
May 1, 2016 at 11:22 am |
You can do this only if you are using the exact same signing certificate. If they are different, Click Once may treat it as a different version and install it again, resulting in having multiple entries in the start menu.
Robin
April 29, 2016 at 1:44 pm |
You can just use url rewrite at web.config, the old program will point to the old url, but it will bring the new program, which will have the new url.
May 1, 2016 at 11:15 am |
Have you actually tried that and verified that it works?
Thx,
Robin
May 2, 2016 at 6:11 am |
Hi, I just tried and unfortunately it doesn’t work. You will get a DeploymentException saying the application is unable to start as it is already installed from a different location.
August 9, 2016 at 9:30 am |
You must have done something wrong. This has been proven successful by many users. Make sure you’re updating the correct URL.
Robin
July 13, 2016 at 4:30 am |
can we do this programmatically to update the url f other locations
August 9, 2016 at 9:29 am |
I’m not sure what you mean. You can write something to modify the URL and re-sign the manifests, but you could also just edit it with notepad and re-sign with mage.
August 7, 2016 at 10:52 pm |
Hello Robin,
Thanks a lot for your explanation. This is a great solution.
However, i’ve a question about a new issue (without use v1.2 during process). Can you tell me if it’s okay ?
The new order :
1) Publish v1.1 in server1
2) Publish v1.3 in server2
3) Publish v1.3 in server1 with update to server2 (with same parameters showed in video)
Have a nice day
August 9, 2016 at 9:28 am |
I don’t think it will work, but feel free to try it out. I don’t understand why you would need to do that. If you are using forced updates, when the customer runs v1.1, it will update him to 1.3, assuming you have set the update URL to server 2.
robin
November 29, 2016 at 10:53 pm |
Totally worked in VS2015CE in my staging env. Will move my production deployment tomorrow morning. The concept is perfect, very clean and precise presentation too. Thank you Robin.
December 13, 2016 at 1:54 pm |
Hi Robin,
I know this doesn’t apply directly to this topic, but I don’t see where to post something new.
I have suddenly started having my ClickOnce applications prompt the users to install (even though there are no updates). I can’t pinpoint it to anything specific happening on the computer (like Windows updates). When this happens, I can see in the registry that entries are missing under computer\HKEY_CURRENT_USER\software\classes\software\Microsoft\Windows\currentversion\deployment\sidebyside\2.0\components. Once I install the program again, the registry is populated with information again.
I personally have had the programs require re-install about 4 times in the last 3 weeks. Not every day.
Anyone have any ideas of what could be clearing out the registry information, or making the computer not recognize that the program is already installed?
Thanks, Chris
February 25, 2017 at 5:28 pm |
Maybe check to see if you have some kind of anti-virus program removing the application? Are the files still in the user’s profile (under /Apps/2.0/ or something like that)? Is it being completely reinstalled, or is it just the registry settings? Also, I don’t think the ClickOnce registry entries go in the place you’ve specified above. What entries specifically are you talking about?
February 9, 2017 at 9:06 am |
Just to let you know that your explanation worked perfectly! Many thanks!
February 23, 2017 at 6:40 pm |
Hello Robin,
I am maintaining our application on two web servers, as we always deploy latest changes to sever1 and after it is stable then deploy to server2.
In this situation, if the latest application run to error on server1, user need uninstall the server1 build and install server2 build. If they wanna to use latest features, they need unintall server2 build and install server1 build.
I’d like to check with you, is there any better way to switch the builds beside unintall/install?
Thanks,
Baomei
February 25, 2017 at 5:24 pm |
Sorry, but there’s no way I know of to switch a Click Once deployment back and forth between two URLs other than uninstalling and reinstalling it.