Open apps should continue to use whatever versions of whatever shared libraries they launched with. As they are closed and reopened, they should pick up the newly installed components invisibly.

If you are (as I gather from the post) writing .NET software, you are committing essentially the same sin. To install one of your applications, a user may need to upgrade their runtime (say, from 1.1 to 2.0).
That would require shutting down any process running the previous version, and after Vista that includes operating system components.
You shouldn’t need to stop the applications, you say? Well, there’s no good way to make this happen.

Of course, it’s normal to expect that an application would be stopped in order to update it, but I see no good reason why other unrelated applications should have to be stopped also. As for .Net runtimes, I agree, it’s not that clean - Java is cleaner as I can pack a private JVM along with the application.

Shutting down unrelated applications may not be avoidable when the Framework is being updated, but I guess that a majority of upgrades are not that critical, and they still require a general anesthesia of the system. It’s normal to expect that you need to move out for a week if the new central heating system is installed, but you would not expect the same if when you buy a new TV set. Shutting down the system for application upgrades might have been
justified in the past (and still is when a key security patch or system upgrade is being applied), but I don’t really think that most of the application upgrades can justify it today.

Maybe you can’t have your cake and eat it too, but you don’t need to keep the fridge door open while you are eating it.

If you are (as I gather from the post) writing .NET software, you are committing essentially the same sin. To install one of your applications, a user may need to upgrade their runtime (say, from 1.1 to 2.0). That would require shutting down any process running the previous version, and after Vista that includes operating system components.

You shouldn’t need to stop the applications, you say? Well, there’s no good way to make this happen. You need to restart applications to refresh the code running in them, which is typically the point of applying security patches.

I suppose the moral here is that you can’t have your cake and eat it too.

fair enough, I should have been more precise. But you’ve missed my point:

So you want everyone to statically link a library instead of using wininet.dll. Fine. Now a security flaw is found in some prior version of the code. Now what? You now need to apply 50 patches, instead of one. How’s that for “ease of use?�

In this case, neither IE nor MSN messenger (and especially not VS) should be updating that DLL - windows update should take care of that. I consider wininet a part of the system kernel, not MSN messenger. Third-party messengers like GAIM and Skype still use wininet, but do not require half of the system to be shut down to install or update properly.