What kind of problems arise from installing a new program while other programs are running? I'd imagine the GAC solved a lot of the old problems of shared dll's being locked. So what kind of issues still arise? I can see issues with upgrading a single program for sure, but outside of this its hard to see why apps would stomp on eachother's toe's.

  • This is only needed for crippled operating systems. With better systems, your can install binaries or libs while old versions are still running or in case of sshd network connections exist. – ott-- May 18 '15 at 19:59

GAC only helps with .NET assemblies. There a lot of other applications which are not written in .NET.

What else problems exist?

  • Other applications holding files open
  • Other applications holding network connections open
  • Other applications holding devices open
  • Other applications slowing down the machine so that an unexpected timeout somewhere may occur leaving the work interrupted
  • Other applications modifying files and settings in the system the installer would expect to stay unchanged during the process (consider it transactional integrity)

Why risk failing the installation process when it is sooo easy to stop other applications and just wait out a few minutes? Go have a cup of coffee in the meantime. :)

| improve this answer | |
  • 10
    +1 What? Theres programming outside .NET? What is this, 2010? – P.Brian.Mackey Jan 5 '11 at 20:22
  • 3
    In what way is it so easy to stop all other applications and then open them up again with the same configuration, so I can continue working where I left off? Or does somebody involved expect developers to work in independent short tasks that are perfectly interruptible? – David Thornley Jan 5 '11 at 20:32
  • 2
    @David Thornley: You don't install things every hour do you? I for instance installed the tools I need once, made an image and haven't had major installations since months. – user8685 Jan 5 '11 at 20:36
  • 1
    @Brian : Correction, 2011 ;-) – Joris Meys Jan 5 '11 at 20:44
  • 2
    @Developer Art: Not every hour, but sometimes I want to get a specific tool for what I'm working on, and sometimes one of my existing tools decides it'd like to update using an installer. Besides, I get annoyed when I can't do stuff on MS Windows that I'd just normally do on Linux or Mac OSX. – David Thornley Jan 5 '11 at 21:16

You can't overwrite a DLL or EXE that is in use by another app. The better written prompts say "look, either close stuff that is using things I want to update (and gives you a list) or continue the install and we'll have to reboot after to replace the DLL/EXE then." The lazy ones just blindly tell you to close every single thing you have running, just in case.

I hate rebooting. I hate closing stuff I'm using. Sometimes I just keep right on rolling and don't close anything that's running. I have a bit of a guess if things might share a DLL, so for example if I am updating Word I'll agree to close Outlook, but not Foxit Reader, I know they're probably independent. I pay more attention to non-lazy prompts (that tell me what the conflict involves) than to lazy ones, which may as well say "may contain peanuts" for all the thought that has gone into them.

| improve this answer | |
  • 6
    +1 for "may contain peanuts". Also for prompts that list conflicts. – Craige Jan 5 '11 at 21:32

maybe the installer is just overly paranoid? in all honesty, I have never ever closed all programs when an installer asked me to do so and never ever got into trouble. Might just be luck though.

| improve this answer | |

A lot of times that message is just inserted as default text for the installation system being used. 9 out of 10 times it can be ignored. Its just that 10th time you have to worry about :-) imo, in addition to the technical reasons DevArt summarized nicely, it was probably put in there originally so that end users dont go screaming to vendors about lost work if the installer crashes Windows and causes them to lose important spreadsheets and documents that were being worked on - a not too uncommon occurrance back in the day when installing software.

| improve this answer | |

The possibility of conflict between application being installed and already running one is very small. These days most applications are based around concept of sandbox and they don't need to step out of it during installation process (or normal usage).

But lets suppose while installing some software, a change needs to be made to a file that is very likely to be already open by another application. You have two choices here:

  1. check if the file is open/locked, figure out which process is holding a lock, display a nice dialog asking to close that specific application
  2. just ask the person to close all the applications and you're on a safe side with no extra effort

Sadly, the second option gets picked up most of the time.

| improve this answer | |

it's hedging. i never bother, and have had no trouble. the only exception is installing a plugin when the targeted app (IE, FireFox, Visual Studio, etc) is still open

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.