Updated VS2019 - why exaclty do I need to reboot?
-
When I start an OS update, I think it's reasonable that I might have to reboot. It's the OS. Visual Studio is an application. It has no business needing to reboot. Or maybe MS developers suck (sarcasm). Still wondering why.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
The last time I looked into it, it was because Visual Studio likes to run background services - you know, those notifiers that let you know "there's an update waiting". I got stuck in a loop once where the service actually got stuck, and was preventing the rest of an update from running and I got into a reboot-find-directory-delete-race, to try to erase the service before it auto-started. Took a couple of tries as I recall...
-
Replace an exe while it is running, then we talk :) Or better yet, mail MS on how they should replace running executables. Same goes for libraries in use by several exe's. Try replacing those, while they execute :D
charlieg wrote:
I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS.
You wanna pay NVIDIA pricing for every component on your PC? I can do the same; just TCP/IP communication on the localhost, instead of coupling. That'd be the technical option, instead of downloading crap and claiming it to be an update, just to show some ads and the line that "umpteen devices use Java.", without any real changes. I hate the Java Updater a lot more than Windows Updates that can be explained.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
Replace an exe while it is running, then we talk :)
How about the same way everything else does - Close the program, launch another one that re-names the original, then re-launch it. Imagine you had to reboot your PC any time Steam (Or any of its included games), or Windows Defender definitions or etc. updated. You'd be rebooting half a dozen times a day!
-= Reelix =-
-
So I have an a$$ton of work going on. Multiple VMs zooming along, editors all over, yada yada. Converted a project from ancient VS to VS2019. I was prompted to update VS2019. Now I have this Installer prompt that says: "Success! One more step to go. Please restart your computer..." Why? Seriously, why do I need to reboot? It's just a holdover from the "reboot Windows" it might fix it history. Or is VS really doing things to the OS that requires me to reboot? I'm not being sarcastic here. Help me understand.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Eddy Vluggen wrote:
Replace an exe while it is running, then we talk :)
How about the same way everything else does - Close the program, launch another one that re-names the original, then re-launch it. Imagine you had to reboot your PC any time Steam (Or any of its included games), or Windows Defender definitions or etc. updated. You'd be rebooting half a dozen times a day!
-= Reelix =-
Reelix wrote:
How about the same way everything else does - Close the program, launch another one that re-names the original, then re-launch it.
That works for your application. As I already explained,
Eddy Vluggen wrote:
Same goes for libraries in use by several exe's.
So, explain how you update a DLL that is in use by several other applications/services?
Reelix wrote:
Imagine you had to reboot your PC any time Steam (Or any of its included games), or Windows Defender definitions or etc. updated. You'd be rebooting half a dozen times a day!
Those don't require a reboot because they don't update a shared resource.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Dave Kreskowiak wrote:
or other shared components or runtimes that are in use by other applications. Those files cannot be replaced until they are released by the other applications using them.
The only question I have is: Have they ever looked into UNIX/Linux/Minix code (it is open source)? Not that I state that *nix OSes are better in all possible ways, but still there is room for learning...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
I haven't used Unix derivatives for a few years (except MacOS and WSL), but I remember they needed to reboot as often as Windows if you install or update stuff.
-
I haven't used Unix derivatives for a few years (except MacOS and WSL), but I remember they needed to reboot as often as Windows if you install or update stuff.
It is true that to use specific updated features (like new kernel) you need a reboot, but you can do it whenever you want to - two weeks from now if you are in the middle. But app updates - for instance your browser - are totally different. You can keep you running application, which will use the old libraries as long as it runs, but a new instance will load the new libraries with the new features... And you need no reboot of the system for that... And it was like this from the very beginning of UNIX...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
charlieg wrote:
Visual Studio is an application. It has no business needing to reboot.
It does if you're using C++ or other shared components or runtimes that are in use by other applications. Those files cannot be replaced until they are released by the other applications using them. At the time of installation, the files are locked, so during the run of the installer, they are queued up to be replaced on the next O/S start since that's the only time the O/S can guarantee they will not be in use by other applications.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakThis was the beauty of the OpenVMS versioning file system. A new image could be laid down - it'd get a new version number. All the older images would still be available to those programs that were using them. When those programs restarted they'd get the new image.
-
I haven't used Unix derivatives for a few years (except MacOS and WSL), but I remember they needed to reboot as often as Windows if you install or update stuff.
Hm, the only time I had to reboot my Linux box is when I updated to a new kernel or did a whole system update (version 1 to version 2 type update). Everything else just seems to update without requiring a restart. Over all, Linux has caused me had way fewer issues that Windows 10 has.
-
Dave Kreskowiak wrote:
or other shared components or runtimes that are in use by other applications. Those files cannot be replaced until they are released by the other applications using them.
The only question I have is: Have they ever looked into UNIX/Linux/Minix code (it is open source)? Not that I state that *nix OSes are better in all possible ways, but still there is room for learning...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Exactly. I haven't restarted my Centos server for ages. And I have installed and uninstalled tonnes of things. A software should just use it's own codes, contained in it's own folder. If several softwares shared same DLLs, and the latest/newest DLL downloaded by the new software is incompatible (in some minor things) to the the oldest software sharing the same DLL, won't this break the old software? Bad code management by M$. They might have done this to save disk space, but, as far as I know, these redistributables have very small size.
-
Windows locks executables (including DLLs) while they are in use. Because of this, in order to update shared components, the locks must be freed. While it's possible, there's no "clean" way to even determine who holds a lock that I know of (unless it was added to a more recent windows in which case I am wrong) so the safest thing to do is reboot. VS uses a lot of shared components. A lot of windows applications do, and generally, the larger/more complicated the application, the bigger your odds of having to reboot on update, because they typically use a lot of shared components increasing the odds that one of them is locked and the app needs to update it. This also applies to the various OS features and shell widgets and doodads, not just applications. I hope that clears it up.
Real programmers use butterflies
VS (which is an additional app, which we specifically download and install) shouldn't have shared components with OS / other applications. I can understand if it's OS bundled application...
