Jason Zander is Corporate Vice President for the Visual Studio team in the Developer Division at Microsoft. Learn more about Jason.
More videos »
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.
One 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!
Jason
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.)
@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
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:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=455333
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=455103
Hey Jason,
What about this bug:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499420
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:
https://connect.microsoft.com/Connect/Feedback
#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 :)
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 ?
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>
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.)
Another one:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=357967
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.)
And one more:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=357962
This still isn't fixed.
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?
@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.
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?.
Thanks.
Since you're the go to guy, I'm going to bug you with one more piece of unbelievable incompetence by Microsoft:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=504654&wa=wsignin1.0#tabs
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.
@RichardHaber
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
@Joe
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.