<p>I have a three-tier application which is installed in corporate environments. With every server version update, all clients have to be updated, too. Currently, I provide an MSI package which is automatically deployed via Active Directory, however my customers (mostly with 20-300 users each) seem to hate the MSI solution because it is</p>

<ul>
<li>Complicated to get it running (little Active Directory knowledge);</li>
<li>The update process can't be triggered by the server, when a new version is detected;</li>
<li>Customers can't install multiple versions of the client (e.g. 2.3 and 2.4) at the same time to speak to different servers;</li>
<li>The update process itself doesn't always work as expected (sometimes very strange behaviour healing itself after a few hours)</li>
</ul>

<p>I've now made a few experiments with ClickOnce, but that way to unflexible for me and too hard to integrate in my automated build process. Also, it produces cryptic error messages which would surely confuse my customers.</p>

<p>I would have no problems to write the update logic myself, but there the problem is that the users running to self-updating applications have too restricted rights to perform an update. I've found that they are able to write to their Local Application Data directory, but I don't think this would be the typical place to install application files into.</p>

<p>Do you know a way to an update that "just works"?</p>

[{'answer_id': 66384, 'author': 'Rami', 'author_id': 8571, 'author_profile': 'https://Stackoverflow.com/users/8571', 'pm_score': 3, 'selected': True, 'text': '<p>You can somewhat replicate what ClickOnce does, just adjust it for your needs.</p>\n\n<ol>\n<li>Create a lightweight executable that checks a network/web location for updates. </li>\n<li>If there are updates, it copies them locally and replaces the "real" application files.</li>\n<li>It runs the "real" application.</li>\n</ol>\n\n<p>The location for the application files should be determined by permissions and operating system. If users only have write permission to a limited set of folders, then you don\'t have a choice but use one of these folders. Another option is provide an initial installation package that installs the lightweight executable and grants r/w permission on a specific folder such as "C:\\Program Files\\MyApp". This approach usually requires a buy-in from IT. </p>\n\n<p>I hope this helps.</p>\n'}, {'answer_id': 69894, 'author': 'Lex Li', 'author_id': 11182, 'author_profile': 'https://Stackoverflow.com/users/11182', 'pm_score': 2, 'selected': False, 'text': '<p>It is really hard to provide you exact answers because critical information about the client side installer is not explicit. Do you install client side files into Program Files? Then you may meet problems when users are restricted.</p>\n\n<p>You don\'t think Local Application Data is a folder to deploy application, but Google does. Its Chrome browser installs that way on Windows, and its automatic update process is even unnoticable (which may sound horrible). So why not deploy your application into this folder for restricted users? You may find more about Chrome installer here,</p>\n\n<p><a href="http://robmensching.com/blog/archive/2008/09/04/Dissecting-the-Google-Chrome-setup.aspx" rel="nofollow noreferrer">http://robmensching.com/blog/archive/2008/09/04/Dissecting-the-Google-Chrome-setup.aspx</a></p>\n'}, {'answer_id': 1799570, 'author': 'treaschf', 'author_id': 217751, 'author_profile': 'https://Stackoverflow.com/users/217751', 'pm_score': 0, 'selected': False, 'text': "<p>If you don't want to give your users too many rights, it is possible to write a Windows Service, which will run on each computer under an account with the appropriate privileges, and which can update your application, when a new version gets available.</p>\n"}, {'answer_id': 3561573, 'author': 'synhershko', 'author_id': 135701, 'author_profile': 'https://Stackoverflow.com/users/135701', 'pm_score': 2, 'selected': False, 'text': '<p>Here\'s an open-source solution I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible. It should give you all the flexibility you need for all that you have described.</p>\n\n<p>So, <b>integration</b> is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also <strong>highly flexible</strong>, and lets you determine what tasks to execute and on what conditions - you make the rules (or use some that are there already). Last by not least is the support for <strong>any updates source</strong> (web, BitTorrent, etc) and any <strong>feed format</strong> - whatever is not implemented you can just write for yourself.</p>\n\n<p>Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.</p>\n\n<p>This boild down to one DLL, less than 70kb in size.</p>\n\n<p>More details at <a href="http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/" rel="nofollow noreferrer">http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/</a></p>\n\n<p>Code is at <a href="http://github.com/synhershko/NAppUpdate" rel="nofollow noreferrer">http://github.com/synhershko/NAppUpdate</a> (Licensed under the Apache 2.0 license)</p>\n\n<p>I plan on extending it more when I\'ll get some more time, but honestly you should be able to quickly enhance it yourself for whatever it currently doesn\'t support.</p>\n'}]
['https://Stackoverflow.com/questions/66007', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/6358/']