11

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

sophieJ
  • 149
  • 1
  • 5
  • What part of the program does the fix apply? UI only? I guess you could use something like MEF to unload and reload the updated code. – eandersson Mar 28 '13 at 14:23
  • This question could be interpreted as allowing the update to take place (i.e. overwriting files) without forcing a close but that the app doesn't need to reflect the changes until optionally closed and reopened, which is a lot easier in most cases than applying a path to a running program that should be seen immediately without re-running it. – Grant Thomas Mar 28 '13 at 14:25
  • @eandersson: The position wasn't explicit. Nonetheless, how will you approach if it is a UI fix or fix in a dll which is already in process virtual space ? – sophieJ Mar 28 '13 at 14:34
  • @eandersson:One solution which I propose to interviewer was that, if it is a dll, then you can have it installed on GAC and have config point to the latest dll. But i failed to expand my solution since I forgot the attributes in config. However, he said no to it because of sensitivity of the dll and can only afford to be private assembly. – sophieJ Mar 28 '13 at 14:49
  • Even if you could hack a program loaded in memory you are still left with if it is processing data how would you keep the data consistent? If it is a monitoring only application then possibly have the new version as a separate install. Start it and then stop the old and delete it. But that is not technically "patching". – paparazzo Mar 28 '13 at 15:01

4 Answers4

4

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.

Dan Puzey
  • 33,626
  • 4
  • 73
  • 96
1

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.

Joe Enos
  • 39,478
  • 11
  • 80
  • 136
0

First, you need to know if this app relies on configuration files such as xml, ini or any form of text based files. If so, can the patch be inserted as a config as long as are they editable out of scope of current process.

If the first solution is not viable, then the second solution to find out whether the running application has a dependable dll and whether injecting a patch as dependency through the reference dll would fix the issue temporarily until a restart being invoked.

Jegan
  • 1,227
  • 9
  • 16
  • How would you "inject a patch" at runtime? And how would you insert a patch in a config file? – Dan Puzey Mar 28 '13 at 14:35
  • you cannot change the binary that has already started, the only way the expected behavior can be changed by parsing parameters as long as the running application has a capable public API, that takes parameters from outside to change its behavior. It is like using a python script to change the behavior on a running application. – Jegan Mar 28 '13 at 14:41
  • Not necessarily true; you can't change the application itself, but you *can* change what functionality an application is running. Text-based configuration is not the only way. – Dan Puzey Mar 28 '13 at 14:45
  • One solution which I propose to interviewer was that, if it is a dll, then you can have it installed on GAC and have config point to the latest dll. But i failed to expand my solution since I forgot the attributes in config. However, he said no to it because of sensitivity of the dll and can only afford to be private assembly. – sophieJ Mar 28 '13 at 14:48
  • @ Dan Puzy : Yes that is true, although text-based would be first simple step I suppose. – Jegan Mar 28 '13 at 14:49
  • @SophieJ : Did you offer using python scripts on available public API on the running app? – Jegan Mar 28 '13 at 14:51
  • @Jegan: Not sure what you are talking about. what is the relevance of Python script in .NET (UI) thick client application ? – sophieJ Mar 28 '13 at 14:56
  • @Jegan: What available public API? You're assuming that there's a configurable API available that somehow allows you to fix bugs. The question says that you need to fix a *critical issue in a running application*; I would assume that the intent is to change the behaviour of the code *beyond* what is possible through configuration, else it wouldn't be so critical. – Dan Puzey Mar 28 '13 at 14:57
  • @ Dan Puzzy, @ SophieJ: all public functions are invokable through external scripts, as we only know there is a critical issue in the application but there are no clear details what and where. the assumption I was making is that if the critical issue was a cause of a function(s) invoked in undesirable order, we could correct that through scripts. This is just an assumption. – Jegan Mar 28 '13 at 15:07
-2

Rename the old file to something else (like add "Old" to the filename), and copy in the new executable in its place, same filename. Next time it gets run, the new executable will get run.

Michael Ross
  • 572
  • 4
  • 7
  • You can't rename something in use. This would only work for data files that are only read in once during loading. – JeremyK Mar 28 '13 at 14:28
  • @JeremyK That depends on _how_ it's being used, as you point out with data files. An executable can often be overwritten just fine even when currently running. – Grant Thomas Mar 28 '13 at 14:29
  • This is not renaming some file. rather, implementing a fix in dll which is already loaded in the process/virtual space. Think a scenario where traders are using this application to capture the market feed where lag is not affordable . This is just an arbitrary example for the application usage. – sophieJ Mar 28 '13 at 14:31
  • @sophieJ The trouble is, the desired ultimate result is ambiguous. – Grant Thomas Mar 28 '13 at 14:32
  • @GrantThomas: Do you want me to elaborate more on the problem space ? Or can you be specific on area where you find ambiguity. – sophieJ Mar 28 '13 at 14:38
  • @sophieJ I explained the ambiguity in my comment on the question: it's open to interpretation. – Grant Thomas Mar 28 '13 at 14:39