We are currently reviewing the feasibility of delivering a scripting capability in a future version of Visual Studio. Please continue to offer your comments on what scripting capability we should offer while we research this suggestion.
Tony Goodhew, Program Manager, VS Pro.
The next version of Visual C++ (v11) will already implement a few new features, the ones highlighted here (http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx).
We’re definitely looking at options to get more features into people’s hands before a complete release cycle (before v12). It would be premature to say anything more specific right now. Hopefully, in the coming months, we’ll have more to say about that.
@Anonymous It's worth remembering that the Visual C++ compiler pre-dates GCC, so an argument could also be made for the converse.
I don't really think that command line switches the two compilers use are that big a deal though. As you observe writing a wrapper isn't difficult.
@dbu Wasn't aware of that - thanks. That beiong the case we can't use VC11 - XP is still way too common amonst our customers, so until it drops to the sort of usage levels seen for NT4 and Win2k we won't be upgrading.
@Shy there's an erroneous right bracket on the link - the actual link is:
@Simon just::thread (which implements C++ 11 threading with VS08 and VS10) works just fine on XP, so it's obviously not a fundamental limitation.
As we aren't able to dictate the OSs used by our customers (rather it's the other way around) if XP support wasn't there it would be a deal breaker for us - at least until XP dies down to the current level of Win2k in the marketplace.
@dbu AFAIK VC11 won't run on XP, but apps developed with it should be able to. If that weren't intented to be the case, why would the VC11 remote debugger support XP?(see http://www.microsoft.com/download/en/details.aspx?id=27540).
"In fact, the loud and clear, yet massive claim for C++11 came when we posted this article a few weeks ago. In UserVoice, the request to include more C++11 features was created on August 25 and then rapidly spiked from 0 to the current 1040 votes, being today the most voted C++ request."
I just don't buy that as an indicator of real interest.
The reception of C++ 0x (as it was then) features during the development of VC10 (which was touted in MS blogs at the time) alone should have told you that support for the new standard would be important. If you dig back through your blog comments to 2009 or so you will find plenty of interest then, believe me.
If even that wasn't enough, just a peak at the buzz that was being generated by the forthcoming standard (e.g. the ACCU Conference had a full C++ 0x track as as back as 2008!) should have told you all you needed to know about the likely importance of it. The online community elseware hasn't exactly been quiet on the subject, either.
I'm quite simply stunned that the MS dev team could even think that C++ 11 support would be less than critical in the first new VC++ release after the release of the new standard.
And needless to say very, very disappointed. As Kryten would undoubtedly say "only a yoghurt" could miss something so obvious.
I’m going to mark this as completed so you can get your votes back – note that Matthew Johnson has released a VS 2012 color theme editor as you requested (link below) – I know it doesn’t have everything you requested in this idea, but hopefully this helps to address your feedback.
Doug Turnure – Visual Studio PM
@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.
UPDATE: This SKU is now available for download – details here: http://blogs.msdn.com/b/visualstudio/archive/2012/09/12/visual-studio-express-2012-for-windows-desktop-is-here.aspx
Thanks for all the feedback on this item. As you may have seen, we will plan to release a Visual Studio 2012 Express for Windows desktop this Fall. Full details are here:
Doug Turnure – Visual Studio PM
PS – I’m going to go ahead and close this item out and release your UserVoice votes back so you can apply them elsewhere.
We will be adding this capability post Dev11 – please refer to the vcblog post for details: http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx
thanks, and thank you for letting us know how important this was to you.
Doug Turnure, VS Program Manager
PS – Per request of a few folks, I’m going to go ahead and close this item out and release your UserVoice votes back so you can apply them elsewhere.
@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.
Thank you to all who provided ideas and votes on this topic. We used that data to help prioritize the improvements in Visual Studio 2012 and have been continuing this work with the VS 2013 release.
As Visual Studio 2013 Preview has now shipped, we’d like to close this item to give your votes back to use on specific topics. Our Visual Studio performance team will continue working to improve performance at an ongoing basis. However, we are closing down this general idea, so that you can use your votes on more specific performance topics, and help us focus our team’s investments. When you have performance related suggestions, please create or vote on specific Perf ideas here: http://visualstudio.uservoice.com/forums/121579-visual-studio/category/52115-performance
Please use Visual Studio 2013 Preview (http://go.microsoft.com/fwlink/?LinkId=306566) and continue your feedback and votes– we highly value your feedback.
Visual Studio Team
@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.