6

We have an .Net application which uses ClickOnce to auto update. But the problem with Click Once is that all the assemblies get updates no matter any change happens in a project or not. I am thinking to manually update only changed dlls into previous ClickOnce published folder and updating manifest using MageUI.exe. I am also thinking to increment changed assemblies version so that we could track what assemblies have changed by looking at the user's cache folder in which ClickOnce app gets installed. I would like to know is this an acceptable approach? Thanks.

FIre Panda
  • 6,537
  • 2
  • 25
  • 38
  • Sounds like a problem waiting to happen if you ask me. What if one client misses a specific "in between" update. He will get a new version, but that may not contain some of the changes introduced in the previous version that he didn't get. – user1429080 Jan 26 '17 at 10:34
  • So, after a click once installation we would check verifiy the version # of all the dlls. So, if update 1 has a dll with version # 1.1.1.1 and update 2 has another dll with version 1.1.1.2, then update 3 click once installation should have dll 1 with version 1.1.1.1 and dll 2 with version 1.1.1.2 along with the changes that gets introduced in update 3. Actually, the latest click once release would be updated to add incremental dlls using mage ui and all clients would get the same release so, if a client is at an older version, he too would get updated to latest. – FIre Panda Jan 27 '17 at 03:56
  • But doesn't that mean that each release will have to have everything in all the previous releases + the changes for the current release? Meaning, each release will get "fatter" until at some point the next release will need to have everything included? Anyway, as far as I can tell, the only way to support upgrading from *any* old version to the current version is to include everything in each release. If you have a limited set of users, and are able to control that they update regularly, then maybe this could be made to work... – user1429080 Jan 27 '17 at 07:14

1 Answers1

5

I think this is not necessary. While the update dialog provided by ClickOnce does not tell you so, ClickOnce will not download files when the following conditions are met:

  • The file's hash is the same
  • The file's time stamp is the same.
  • For assemblies, it may be necessary to strong-name them

Instead it will copy the files from the previous version.

So if you use strong names and do not rebuild assemblies when they have not changed, ClickOnce should do exactly what you want it to do.

See here and here for reference.

Here is the official source saying

When updating an application, ClickOnce does not download all of the files for the new version of the application unless the files have changed. Instead, it compares the hash signatures of the files specified in the application manifest for the current application against the signatures in the manifest for the new version. If a file's signatures are different, ClickOnce downloads the new version. If the signatures match, the file has not changed from one version to the next. In this case, ClickOnce copies the existing file and uses it in the new version of the application. This approach prevents ClickOnce from having to download the entire application again, even if only one or two files have changed.

Community
  • 1
  • 1
wkl
  • 1,896
  • 2
  • 15
  • 26
  • Yes, thats true but when the solution is build, all the assemblies' manifest changes no matter there is any code changes to it or not. – FIre Panda Jan 30 '17 at 03:57
  • Yes, you are right. You would have to put the projects into different solutions and manually update referenced assemblies in your 'main' project. I agree that this is much less convenient than having them all in one solution. But still IMO it is much better than trying to force ClickOnce to do a partial update when the hash signatures have changed. – wkl Jan 30 '17 at 07:11
  • For our application we have had to set the flag Full-trust application in project settings for partial dll update too, not just strongly naming – VMAtm Apr 05 '17 at 20:38