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