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.
@Jeff Why thank you!
I always try to write code that I (or anyone else working with me) can maintain without unnecessary difficulty (preferably even on a bad day when they have a hangover and when the coffee has run out...).
As a result I try to write in a style that's consistent, readable and doesn't do anything unexpected (at least, not without a comment to indicate it's doing something unusual and why).
I try to use static analysis (mostly PC-lint, but not exclusively) and measuring cyclomatic complexity to remind me not to wander too far away from my ideals. Although a lot of the issues analysis tools find are harmless at the time, I've learnt over time as the code evolves new code paths can make some of them harmful - so I fix them up front as a matter of course.
I also compile at warning level 4, of course - and at times I've even found "Warnings as errors" to be a useful project setting.
Of course the behaviour of any analysis tool is always going to be a compromise. Where my style and a tool disagree, I tend to try to be humble and accept that it's easier for me to adapt than to try to get the tool modified to accept my oddball way of doing things.
It probably doesn't hurt that I enjoy refactoring, either. :)
Anyway - I think we're wandering way off topic for this thread...
@Jeff I've been working on Visual Studio plug-ins since VC6 days, and after a while you start to see patterns.
FWIW I started using PC-lint heavily as a result of being involved with a project which had a growing quality problem. It not only helped us fix the things we are looking for, but found quite a few issues we hadn't even suspected were there. What I do now is a direct result of wondering about how we could make that process a bit easier.
But I digress. YMMV, of course.
@Jeff thanks for the information.
AFAIK the only one of those we use is EnvDTE::ItemOperations::OpenFile() - I've not noticed any regressions in that case, but I can certainly take another look.
It's probably no consolation but we're *very* used to seeing regressions on EnvDTE (and VCProjectEngineLibrary) interfaces when a new version of Visual Studio arrives. For example, VS2010 had completely broken command bar interfaces on release.
EnvDTE seems to be the poor relation of VSX, and (I assume) doesn't get seem to get tested anywhere near as exhaustively as the VSPackage interfaces that Visual Studio language services rely on. That's not to excuse that of course - but it's not a new pattern in VS2012 and VS2013.
Finally: I'm not a heavy user of macros, but removing support for them is nuts. If it helps, I wouldn't be surprised if it wasn't an intentional omission but happened as a consequence of re-engineering elseware and them running out of time (like in the case of the C++/CLI intellisense *****-up a while back).
EnvDTE actually works the same way in Visual Studio 2012 as it does in previous versions (our Visual Lint plug-in uses those interfaces).
However, the ability to write macros which use it has (very wrongly, in my opinion) been removed.
Thanks for the feedback about adding Mercurial as a source control option for TFS.
At this time, we are not planning to add support for any additional version control systems to TFS. The addition of Git to TFS provides teams with the option of the preeminent distributed version control system or the existing centralized version control system, TFVC. For developers that are specifically looking for Mercurial support, one option is to use the Hg-Git plugin that aims to losslessly convert Git commits coming from a Git server to Mercurial changesets.
TFS Program Manager
Support for C++11 began in Visual Studio 2010, which included auto and lambda functions. In Visual Studio 2012, we implemented more of the standard—for example, range-based for loops, standard threads, and futures. Visual Studio 2013 provides even more—variadic templates, delegating constructors, non-static data member initializers, uniform initialization, ‘using’ aliases, and other features.
For more information, see the C++ Conformance Roadmap on Soma’s blog (http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-conformance-roadmap.aspx) , and learn about the Future of C++ from Herb Sutter (http://channel9.msdn.com/Events/Build/2013/2-306).
Finally, this table summarizes conformance by feature, http://msdn.microsoft.com/en-us/library/hh567368.aspx.
Visual C++ Team (ebattali@Microsoft.com)
@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.