VS2010 Beta 2 Feedback Survey

Last week we shipped Beta 2 for broad distribution.  Many of you have already sent us comments and improvement suggestions (thanks!)

At this point we are down to our final set of bug fixing, perf tuning, etc.  I’m very much interested in your feedback so we can take action on it before we ship the final version.  To help make it easy, you can take this simple survey.

imageOne thing in particular I am hearing a lot of feedback on is performance.  We are working hard on the next round of perf improvements.  You can supply your feedback through the survey.  When you give us your feedback, the more actionable you can make it the better.  We need to know what operations you are doing (like editing, debugging, etc), what kind of hardware you have (CPU, RAM, disk), and your hosting scenario (main machine, running in VM, terminal server, etc).

thanks in advance for your feedback!


Comments (32)
  1. Joe says:

    There seems to be a major disconnect between the evangelists, such as yourself, and the people who actual handle bug reports and feature requests on Connect. You ask for feedback, but the people who run Connect close many reports as won’t fix or by design. Sometimes, they focus only on the work around without acknowledging a reproducible bug.

    The amount of goodwill Microsoft has squandered in the developer community is nothing short of stunning. A big result of this is very experienced developers are either not participating in this beta or they are quitting the beta program out of frustration. I am quite close to the latter.

    (I ran across a splitter window bug. It’s similar to one I filed before, but I already know that after a professed confusion about what I mean, it will be declared "by design" though if someone actually did design it that way they’re pretty dumb. End result, I’ve decided to not bother filing it. It’s just not worth the aggravation.)

  2. Jason Zander says:

    @Joe – I actually run the engineering team so I’ll take the blame for the Connect responses (my folks).  We are in the process of tracking all the Connect bug feedback right now and will be working to resolve issues.  Thanks for providing your feedback through the system.  If you have some examples that are really bugging you, please do send me the connect ID and I will follow up.  thanks, Jason

  3. Dan says:

    I was actually very pleasantly surprised by the performance increase in beta 2.  Start up speed is almost on par with VS2008 now, and once loaded, VS2010 actually feels snappier in many areas.  Thank you for finally addressing the Add References dialog issues too!

    Memory usage does seem to still be an issue though – just loading an empty environment, VS2010 is using almost 6x the amount of memory as 2008.  If this is a sacrifice we have to make for performance reasons then I suppose it’s worth it.

    The only thing that’s really, really troubling me with VS2010 is the decision to default the platform target of all new projects to 32-bit.  I just don’t think this has been thought though properly.  Already, the decision has had to be partially reversed after it was realised that defaulting library projects 32-bit would then permanently lock any apps using those libraries to 32-bit as well.

    The industry is moving away from 32-bit and it just seems crazy to make this change now, after all these years of targeting "Any CPU".  We’re in the final stretch of the 64-bit transition and to suddenly switch to targeting 32-bit is shocking.

    If you’re interested in what your customers think of this decision see the following Connect bugs:



  4. SuggestionBoxBob says:

    One extreme oddity about Connect is the inability for others to see screen shots (or any attachments).

    When I create Beta 2 bugs on Connect that involve the UI, I attach screen shots for 2 reasons – 1) obviously, I hope it will help the team that gets the bug assigned to them in understanding the bug and 2) I want *other users* to be able to see the screen shots to confirm that a bug they’re seeing is (or more importantly, isn’t) the same bug I filed.

    In using bugzilla, trac, TFS since before V1 RTM, etc. I’ve never had a system I’ve used that didn’t let others see the screen shots posted.  Even the systems (like RedHat’s internal bugzilla) that had support for "private" bugs (not viewable by the public) still had the concept of public bugs.  Not having *any* option for attachments to be viewable (not even by the person that filed it, funny enough) is bizarre.

    Yet, Connect has considered this By Design for 4+ years now:


    #3 most up-voted active bug

    #3 most up-voted active suggestion

    Any chance you can make some forward progress on this?  If Connect isn’t going to move forward on something like this, I’d frankly rather file VS bugs on codeplex where at least I get a real TFS interface and can do something like view the attachments to bugs 🙂

  5. Raji says:

    i have an error, If i run my website in visual studio 2005,

    unable to connect to visual studio’s localhost web server error is handled wht can i do for that ?

  6. Joe says:

    Here is a good example of a really lousy response on Connect:

    <a href="https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=504714">https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=504714</a&gt;

    Ironically, the issue is probably by design, but not for the reasons given. It appears that the static CRT and MFC release libraries have debug information turned on. I assume that this is also why performance testing has shown VS 2010 to be 20%+ slower in optimized release builds vs VS 2005/2008 (for my tests–may not be true across the board.)

  7. Joe says:

    Another one:


    Still hasn’t been fixed. Just how lazy are you people? And don’t you care that you look stupid and lazy?

    And who is it that still insists on adding a comment at the top of every file that restates the file name?

    (And while ranting; who came up with having stdafx.h include targetver.h which now includes SDKDDKVer.h? Do you have a department there that comes up with ways to make things complicated for no reason? Don’t get me wrong; SDKDDKVer.h is long overdue, but why not have stdafx.h include it directly? More importantly, someone had the time to change the wizards to do something utterly useless, but not anything more.)

  8. I just installed the Beta 2 and am running under 64 bit Windows 7.  When I try to access the ‘View’ menu, the entire IDE crashes.  I posted a bug report on the Microsoft Connect site, but looking for more immediate gratification, you know how it is, right?

  9. Jason Zander says:

    @Dan – thanks for posting your experience; we are working on the memory consumption issue.

    @zproxy – thanks for the pointer, I’ve pinged the team.

    @SuggestionBoxBob – thanks for the feedback on Connect. Your request is a common one.  I’m talking with the Connect site owners to see if we can address this going forward.

    @Raji – can you provide more detail on your issue?  you can contact me through my blog and we can see if we can help.

    @Joe – thanks for posting your issues.  I’ve forwarded to the C++ team.  Things that block your progress will go high on the list; things that don’t block the ability to use the product will not sort as high.

    @Richard – obviously we don’t expect a crash.  I’ve forwarded your issue to the IDE team so we can follow up.  if you can file a Connect issue with a call stack that would help us.

    @thewife – hope you work things out with Don.  As this doesn’t seem to be product related, I’m going to delete the comment and let you work things out with family therapy.  Or a judge.  Good luck.

  10. Fernando says:

    Debug with F11 key it’s not identical to C# Visual studio 2005 or 2008, Yeelow line no track for’s{} c# ; only view local window?.


  11. Joe says:

    Since you’re the go to guy, I’m going to bug you with one more piece of unbelievable incompetence by Microsoft:


    Note the comments that one bug has been found and that icon editing will be unavailable. This is completely unacceptable and a perfect illustration of why us developers are getting very upset and angry at Microsoft. One of the most important keys when updating products is that you provide at least the same functionality as the previous edition. Right now, toolbar customization in VS 2010 simply sucks.

  12. Ryan Molden [MSFT] says:


    Richard, I haven’t been able to reproduce the crash with the view menu locally.  Have you reported this through the Watson error reporting dialog when the crash occurs?  I saw the stack in the Connect bug but without resolved symbols all I can really do is guess at the culprit.  Can you contact me via e-mail and I can continue trying to repro?  My mail address is the first letter of my first name + my last name @ microsoft.com

  13. Ryan Molden [MSFT] says:


     Sorry to hear about your dissatisfaction with the current command UI customization story.  I am the person to blame as I was (for the bulk of Dev10) the sole command UI developer tasked with moving the UI layer from MSO (owner drawn Win32) to WPF.

     Unfortunately the icon editing and drag & drop customization was a piece implemented by the old MSO code in a non-shareable way.  Thus we were faced with either not supporting those two bits in Dev10 or re-writing it from scratch in WPF.  

     As some background MSO was written by an entire team of developers over multiple release cycles of Office.  We had a single developer (me) over a single release cycle (Dev10) and I already had a full plate from the move to WPF and making sure the numerous partners using the command system weren’t broken.

     As you can see the tough call was made to cut these two bits in order to ship Dev10 in a reasonable amount of time given the resourcing constraints we had.  The call to cut icon editing was, in my mind, much easier than the call to cut the drag & drop customization.  I reasoned that there were numerous, dedicated icon editing programs available (many for free) that do a FAR superior job to what we offered ‘in the box’ in Orcas.  So instead of implementing a sub-par icon editor just to have parity we chose to cut it and focus efforts on the bits we considered more of our forte.  

     Feel free to send any more input you have my way, my mail address is ‘first letter of my first name’ + ‘my last name’ @ microsoft.com.  We (the Shell team) really do care about customer experience and are always interested in hearing feedback.  Sometimes we have to make tough calls and not everyone will agree with our decisions, but do know we don’t make them lightly or in an effort to vex our customers.

  14. Daniel Smith says:


    I was also slightly disappointed that we lost the drag and drop customisation on the toolbars.  However, it’s only something I customise once after a fresh install, so it’s not too painful, but it would be nice to have this back in a future release.

    I totally understand the pain of switching to WPF and finding it doesn’t support many of the basic features that we could previously take for granted.  The dire state of WPF (e.g. poor design time experience, loss of productivity etc.) is one of the reasons so many people are avioding it like the plague.

    Hopefully we can also have a real shake up of the WPF controls in the next release in order to improve some of these types of scenarios.

  15. Ryan Molden [MSFT] says:


    >I totally understand the pain of switching to WPF and finding it doesn’t support many of the basic features that we could previously take for granted.

    I am not sure about that one, no framework that I am aware of supports drag/drop customization ‘out of the box’ (i.e. without the consumer writing some code).  The underlying architecture is there on the WPF side to support it, we just didn’t have time to hook it up to the VS side architecture (since we have to persist these changes, make sure DTE is aware of them, make sure they show up properly in the customize dialog, allow export/import of the changes, etc..).  I am going to be talking some with the WPF guys about changes in the Dev11 timeframe, but I don’t think they could do a lot to make this specific feature much easier.

    >The dire state of WPF (e.g. poor design time experience, loss of productivity etc.) is one of the reasons so many people are avioding it like the plague.

    I haven’t noticed a huge loss of productivity, there is a learning curve but that is unavoidable when going to anything new.  Then again I don’t use the designer much, but that is more of a personal preference (and due to the fact I cut my teeth on WPF before the designer was widely available, so I got used to hand authoring XAML).  I have certainly noticed a HUGE increase in time savings when the UI needs to be tweaked or changed drastically.  The sheer rate of churn around some of the UI in Dev10 would have made it an absolute nightmare if it had still been done in Win32 WM_PAINT handlers.  Further seperating the data bits into their own models and seperating them cleanly from the UI has been very good, they were somewhat seperated under MSO but not entirely, which made varying one piece (data or UI) independent of the other a real pain.

  16. Free Help says:


    Could you please provide more details on the specific differences you are seeing in the stepping behavior between VS 2008 and 2010?  Do you have a specific for-loop that demonstrates the issue you are talking about?

  17. Daniel Smith says:


    > I am not sure about that one, no framework that I am aware of supports drag/drop customization ‘out of the box’

    In VS2008, right out of the box, you can get full drag and drop toolbars just by creating a new MFC application project and following through the wizard.  No coding required.

    WPF definitely has its strong points, but it’s still lacking when it comes to creating standard apps that conform to the Windows UX guidelines.  I just don’t think it’s wise for *every* app to come up with its own UI designs unless there’s a really compelling reason.

    Don’t get me wrong though – I do think the declarative WPF approcach is the right direction to head in.  It’s just taking such a long time for WPF to get to state where it’s pleasant to work with.

    That said, the WPF improvements in .NET 4.0 are very welcome additions, but I hope WPF can be an area of intense focus (especially the design time experience) in future versions.

  18. Ryan Molden [MSFT] says:


    >In VS2008, right out of the box, you can get full drag and drop toolbars just by creating a new MFC application project and following through the wizard.  No coding required.

    Ahh yes, that is slightly different than what I was talking about (though I see the confusion).  WPF doesn’t allow us to easily have drag/drop toolbar docking/undocking (short of completely re-implementing ToolBarTray), however the harder part I think is persisting / re-applying that info, specifically for intra-toolbar moves/adds, which I don’t think MFC gives you for free, but I am not an MFC guru so I could be rather mistaken 🙂

  19. Dmitry says:

    When editing a C++ source file, there is a useful command in context menu: Go To Header File. After running this command and switching to .h, I was confused – where is the pair to this command, namely "Go To Source File"?

  20. Jason Zander says:

    @Dmitry – Header files can be included in multiple source files so in a typical case there is no one source file to go back to…

  21. Ryan Molden [MSFT] says:

    @Dmitry – To add to what Jason said, you can use Navigate Backward to accomplish this ‘backwards leap’, unfortunately if you have moved around extensively in the header it will take you to all previous cursor locations before taking you back to the C++ file.  But if you just pop from C++ file to header then Navigate Backwards should take you back to the C++ file you came from.

  22. Hitesh says:

    Suggestion for performance improvement!!!

    – Split ‘Add Ref’ dialog into two separate dialogs which can be accessible thru menu.

     1)’Add .Net Ref’ dialog with tabs (.NET, Project, Browse, Recent)

     2)’Add COM Ref’ dialog with tabs (COM, Project, Browse, Recent)

    – Allow user to RE-SIZE the "add reference" dialog which will help user to see full description of assemblies whenever ‘add ref’ dialog is open/re-open.

    – Allow user to set which TAB will be used as default tab when ‘add ref’ dialog is open or at least provide check-box option like "default to last visited tab"

    – Sort by assembly name

    – Also improve performance when loading control in toolbox after user select assembly from ‘add ref’ dialog box.

    Hitesh (INDIA)

  23. Richa Prasad [MSFT] says:

    @Hitesh – These are good suggestions. Could you file a Connect bug for this so that we can track it for future VS releases? Here is the Connect site:


  24. Chakradhar says:

    while installing vs2010 beta2 on my windowsXp sp2 i am getting error informing "attempt failed to install windows installer 4.5" so i manually downloaded it from microsoft and installed. it is again giving the same error…. whats the reason?

    thanx in advance if u could help in someway…

  25. aaronru says:

    Hi @Chakradhar,

    This is an interesting issue with MSI4.5. In order to help you further, I want to look at your setup logs.  Please run the <a href="http://go.microsoft.com/?LinkId=8967044">collect tool</a> to collect the setup logs.  Then please upload them to somplace like <a href="http://skydrive.live.com/">Windows LiveTM SkyDrive</a> or http://www.file-upload.net/.  Then send a link to me at aaronru(a)microsoft_dot_com.


    Aaron Ruckman


  26. Chakradhar says:

    ya the problem was it was not downloaded properly..again i downloaded and installed its working fine..but to install documentation should i have internet connection compulsory…..and give me one url where i can provide feedback……

  27. Chakradhar says:

    when i run, it is very slow and whenver i am adding new references and controls to Tool Box it is taking very much time . is the problem with my system configuration(1Gb RAM, 1.6GHz,120GB HDD XpSP2). should i change it or any other alternate solution i have..


  28. Richa Prasad [MSFT] says:


    Re: "one URL where I can provide feedback", please log all your feedback on the Connect website:


    Your feedback will be routed to the appropriate team.

  29. Petras says:



    Context Menu: Go To Header File.

    If *.h and *.cpp files are in different directories, then "Go To Header File" don’t work. Why?





  30. Wenbin [MSFT] says:

    Hi @Chakradhar, I’d like to understand more about the toolbox slow-down issue (may or may not be performance related). Let’s discuss it in details offline. My email address is wenbinx@microsoft.com.

    In addition, you could follow the tips from Richa to log the issue via Microsoft Connect site at http://connect.microsoft.com/VisualStudio, provided you’ve done so yet.




Comments are closed.

Skip to main content