I already touched the subject in a couple of previous posts and replying to direct comments and question I got, and to confirm that we’re doing something (hopefully in the right way ) on this matter I want to highlight this news from Jeff: Migrating hotfixes to MSDN Code Gallery.
The essence is that Visual Studio, .NET and other technologies hotfixes can be downloaded directly from http://code.msdn.microsoft.com/Project/ProjectDirectory.aspx?ProjectSearchText=hotfix and start a discussion with other people on the matter, hope you’ll find this useful (and keep the feedback coming of course).
Carlo
What about the "Check for Updates" feature that is supposed to work in VS. It's been there since the first VS and still doesn't "work" in VS2008.
Why depart from the paradigm of "Microsoft Update" which is simple and can even automatically download updates and keeps track of what is installed and applicable to the system.
It's a PITA to get the Hotfixes and keep track of them. Why can't this be made easy for developers? We already have enough to do - keeping on top of and learning new Technologies & Frameworks while still writing code and keeping projects on schedule! We shouldn't have to worry about tracking every individual Hotfix for the Tools that we use and rely upon to do our job every day!
Good point Dave; that command is meant to bring you to Windows Update (or Microsoft Update) to download "official" updates of VS components installed on your machine. Since this process of "free download" for former private hotfixes is relatively new, I guess the VS team (and/or whoever is behind this kind of stragetic decisions) are not confident enough to allow this change (or simply they have not yet seen this opportunity, or there are other reasons I'm not aware of to no have implemented it yet...).
The reason behind having *private* hotfixes is what I tried to explain in this and my other posts on the subject; probably most important is that you are not supposed to install *every* private hotfix but only the ones you really need because you're having the problem resolved by that fix. There is no added value (but potentially some problems) installing *every private* hotfix we release. This is what the VS team is trying to change, it's still "work in progress" so I would not be surprised to see further news in the future (but hey, I'm not making promesses here ;-)).
Anyway thanks for the feedback (keep it coming), I'll report to the team.
In general, I agree with the tenet of "if it ain't broke, don't fix it". That being said there is something to be said for keeping your install as up to date as possible.
There are 5 main issues I see:
1. "Synchronization" between Developer workstations. In other words, *everyone*, including the Build box (if using CI), has exactly the same configuration, environment, and Hotfixes. This extends beyond the Development environment to Integration, Testing, and Production servers as well (however, those don't have VS installed but the principle is the same). I have seen situations where a Hotfix applies and resolves a problem on one Developer workstation yet another workstation doesn't have the same problem. Obviously, there must be some differences between the two. However, because there are no real solutions for doing diffs on machines, the easiest solution is to apply the Hotfix to all workstations. At least we know then there is 1 less difference between the group.
2. The 2nd issue is one of "side-effects". A Hofix can often cause side effects to something that is seemingly unrelated but still affects your application or environment in some unforeseen way. This is often discovered after much pain and agony spending hours and days trying to find out "what happened".
3. The 3rd issue is one of not knowing *exactly* if a Hotfix applies to your problem or not. Often times we will run into an issue and find a Hotfix which seems to be applicable, install it and find that it didn't work. Then continue on looking for the next possible solution. The Hotfixes which didn't apply may never be removed.
4. Hotfixes often have other Hotfix dependencies either from a pre-requisite perspective or from "interacting with one another". I've seen it happen that 2 different hotfixes have unexpected behavior when they are installed on the same machine. Inother words, Hotfix A will cause Behavior A, Hotfix B will cause Behavior B, and the combination of Hotfix A and B will cause Behavior C (instead of A + B).
5. Lastly, in theory aren't all of these Hotfixes eventually rolled-up into a Service Pack anyway? This means you'd have Hotfixes installed regardless of whether or not they apply to your system.
Things keep moving and after some discussion ( here and here I already expressed my view on the matter),