@Nick it's certainly possible to change command icons using the command bar control interfaces in EnvDTE. Changing them in this way does not affect the icons held by the command itself - those are used to create the corresponding command bar control and don't change.

I've not yet checked whether you can do the same with built-in icons (we used icons in our own plug-in for test purposes), but you might be able to - or use a comparable VSX interface to achieve the same aim.

The context for us is that we want to change the icons dynamically to match the active theme, as that way we can use colour icons in the light theme without the dark theme mucking them up.

By the way, if you need to check whether the active theme has changed the best way we've found is to trap the AfterExecute event for Tools|Options, and check the VSCOLOR values at that point.

@Nick, you might want to get in touch with us (Riverblade) as in the process of adding support for the dark theme to our Visual Lint product (see http://www.riverblade.co.uk/blog.php#2012080202) we've discovered a few things which might be relevant to the task you're undertaking (e.g. we've been looking at dynamically modifying icons, and have spreadsheets of all of the VSCOLOR data for VS2010 and 2012).

You might also want to start a conversation with Carlos Quintero (http://msmvps.com/blogs/carlosq/default.aspx) as the chances are he's worked out a few things too.

@Raman as the main reason for us to upgrade would be the improved C+ 11 support in the VS11 compiler, using the VS10 toolchain doesn't help us at all.

So how can we take advantage of the new C++ 11 features in the VS11 C++ compiler while not abandoning the substantial proportion of our customers who are still running XP?

@taspeotis Not if you also wish to use the new compiler - which for us would be the reason for upgrading.

@Mr Partridge very true - I suspect we're talking apples and oranges here.

@Alexei Apologies for the long post - I've a lot to say on this subject, and to a great extent I've said most of it before elseware. Anyways...

> @Anna, on your last point (VS extension dev) you have an huge ally :) VS development team. So even if they couldn't get everything right in the first re-write, they are sure to improve, because it affects them directly, arguably more so than other devs working on plugins/extensions.

One would hope so; in practice I can tell you from experience that extension developers generally have a rough time whenever a major change happens in the Visual Studio codebase - as a browse through Carlos Quintero's blog (http://msmvps.com/blogs/carlosq/) during the period of any of the VS betas should illustrate.

Suffice it to say that the last two VS versions with major changes (VS2005 and VS2010) were still both pretty badly broken at beta 2; at least with VS2010 MS listened to reason and issued a release candidate which meant the RTM was better than it otherwise would have been. VS2005 never had that, and still has noticable breaks (e.g. the Add-In Manager) to this day. By contrast VS2003 and VS2008 were a breeze, which leads me to observe that VS releases follow a two step release pattern - major reelase with breaking changes (VS5, VS2002, VS2005, VS2010), then consolidation release (VS6, VS2003, VS2008).

On the VS2010 front believe me we've had to invest far more time than is reasonable for a new version working around bugs in VS2010 that just shouldn't be there so late in the day - so much so that once again I honestly believe they tried to change far too much in this release (our experience was far worse than VS2005, and that's saying something).

> Still has VS UI ever locked up on you in 2010? Are any of the problems rooted in the fact that UI can't render? Not for me, at least. VS 2005/2008 used to lock up all the time on me (2008 less so), I couldn't keep VS open for more than a day, I would shutdown in the evening and re-open in the morning. The only slowdowns in 2010 for me come from underlying things like parsing projects, compiling, building maps of the large code-base (identifier refences, occurances, etc.), code analysis and re-factoring tools (esp. 3rd party). You can see much more serious issues in Avery Lee's post, none of which seem to be UI issues.

I've not found a version of VS yet that hasn't died or froze on me at some time; same with Eclipse. The worst one for me at least) seems to be VS2005 - something very weird seems to be going in with the internal COM interfaces in that version.

> I am still certain that WPF is a red herring of performance issues. There was massive rework of back-end for 2010, and the fact that the obviously visible change to the user is WPF, makes people correlated WPF with the cause of slowness. Just because they happened at the same time, doesn't mean the two have any relationship.

It may turn out to be - but given the timing of the change between CTP and Beta 1, I'd say the editor work very likely has a (possibly big) part to play.

Regardless, it needs to be sorted. Get the memory footprint and responsiveness of VS2010 to the same level as VS2008 and I'll be a lot happier regardless of what technology they use to do so - WPF, native or whatever. I'm sure others will be too.

> But let's say there is a relationship, and we do pay in performance, look at what we've gained. Text rendering quality in WPF got a huge boost from VS adopting it. The adoption of MS tech by major MS product is nothing but a good thing, they (and us) just need to keep pushing for improvements. Another re-write (as a lot of people demand) so soon will just cause more issue (more fresh bugs). They will be somewhere else, but we as uses will be no better off. The motivations should be to fix the things that are broken, not re-write the same thing over and over (introducing v1 bugs again and again). Old editor and the rest of the UI, was ancient, it couldn't go on, a re-write was needed. Re-writing it again is Sisyphus' labour.

The fact that WPF has evolved as a result is almost entirely irrelevant to me - I'm far more interested in C++ 11!

I'd argue that big rewrites are what got us where we are now (the C++/CLI Intellisense fiasco demonstrated the same symptoms - committing to too large a change in a single release), and that a far more incremental rapid-release approach would work better for VS anyway. If the changes in VS were more controlled and less "Hey guys this is big and new and shiny! Isn't it cool?" I'd be happy to migrate to a new VS SP every 3-6 months, and a new major version every two years.

As it is, we regularly (every second release) skip a major version (we skipped VS2005, too - prior to VS2008 we were on VS2003).

@Alexi I think of it as more of an educated guess than an assumption - bear in mind what I mentioned about the CTPs.

Having seen the far higher number of functionality breaks than usual in the command/editor interfaces of VS2010 during the beta cycle it seems reasonable to assume that the VS team had far bigger problems than perf at the time. Now that VS2010 is at least stable that now needs sorting as a priority.

Spinning up disks may well be a problem too, but I reckon the issue goes significantly deeper than that.

BTW I work on VS extensions, so I start new instances many times a day - often under debug or in VMs. For this, the perf of VS2010 sucks bigtime compared to previous versions.

I run VS on several machines in a typical week, ranging from a netbook (for mobile support) and Core2 and i7 laptops to Q9550 and Opteron x64 machines with > 4GB RAM.

On each of them VS2010 takes *considerably* longer to start up than any other version. Although I wouldn't expect VS2010 to match the load performance of VS2003 or VC6, it shouldn't be *that* much worse than VS2008. But, unfortunately it is. The fact that the pre-WPF editor CTPs of VS2010 were much snappier than the RTM indicates that the editor rework is at least partly to blame.

As a result we're sticking with VS2008 until there is a more compelling reason to put up with the awful performance than VS2010 offers.