Apply update without restarting application [closed]

Question

Recently I had an interview for a .NET position. Out of questions asked, I was having real trouble in answering one question. I hope someone can help me on this.

Scenario (Question): The first release of an application (could that be winform/wpf UI application) is already out to client and they started using the application. But unfortunately, the QA team later found a serious issue in the current release. Now the challenge is that, we should be able to send and apply the patch (fix) without forcing the application to restart. The assumption is that the application is a real-time application which can’t be restarted to apply patches.

Personally, I was having real trouble in giving a convincing answer which doesn’t affect running application while patch is applied.

Answer:

Thank you for all contributed so far. I have managed to get a solution for this issue. Not sure whether this is what the interviewer asked. Nonetheless, I pleased to read about microsoft's ClickOnce, which does almost what I wanted..

Answer 1

For the currently-running executable, you're pretty much stuck - you can't sensibly modify the process running in memory.

However, things loaded from DLLs are much more flexible. Assemblies can be dynamically loaded at runtime, and it's possible to spin up multiple AppDomains within a single application. One solution might be something along these lines:

• your executable is a thin wrapper that passes all functionality through to a DLL
• your DLL functionality is loaded and run through a separate AppDomain
• when a patch is required, the new DLL is copied in (side-by-side with the existing one)
• either automatically or in response to user interaction, a new AppDomain is started alongside the existing one, running the new patch
• at a suitable point in the app (say, a full-screen switch or a timed refresh), the new AppDomain becomes the "live" one
• the old AppDomain is shut down and discarded

However, this is very high-level. In a realistic situation you're quite likely going to have a multi-tier app with caching and live data and many other considerations. It might be necessary, for example, to separate the front-end logic of the application from the caching or data-handling part, so that any one piece can be switched out without disturbing the rest.

Certain uncommon techniques are likely to be useful here, depending on the exact requirement. Advanced caching could allow the data-tier to be swapped out without the front-end losing an ability to display data. Command-queuing or reliable messaging mechanisms could allow the UI to remain responsive while the business tier is swapped out, and the new business tier can then process the queue. If you assume a (logically) server-based app then redundancy at each tier could allow for one redundant "server" of a tier to be updated while the other server continues processing... etc.

Answer 2

If you have this requirement from the beginning, you can separate out your app into two distinct applications - the UI piece, and a service which does all the work in individual atomic function calls. Most likely, your bug is in the service, so you'd be able to replace that application at any time without disrupting the user experience.