[This is Part 1. Read Part 2 here]
Now that we’ve shipped Beta2 and the world is busy downloading the fresh new bits, I’m very excited to know what do you guys think? Will you like it? Will there be major issues that we missed? Time will show :)
By definition, this Beta 2 release is not final, and there are still bugs lurking around out there. We are very busy fixing those bugs for RTM, but for now, there are some that we haven’t had time to fix before Beta2.
This post lists some of the known issues that are in VS 2010 Beta 2. It’s not in my powers to maintain a comprehensive list here, I’ll just mention the ones which I was personally involved with in my day-to-day work. Apologies that I have found them too late, but I guess better late then never...
All further updates will happen there or will wait until Part 3.
Need to upgrade .sln file from Beta2 in order to be able to double-click it. See Jon’s post here for more details:
Embarrassing! Unfortunately, not everyone on the Visual Studio team is rigorous about non-default testing, such as High DPI, Accessibility, etc. We will hopefully fix this one before RTM. Also recent data shows that non-96 DPI is a very common setting, a lot of people actually use 120 DPI and others. I personally use 120 DPI, that’s how I find these bugs.
With high DPI, the SmartTag menu is missing horizontal menu separator bars. Also the right vertical edge of the SmartTag button disappears. These bugs are a recent regression from WPF introducing the UseLayoutRounding API. The WPF team is looking into fixing these issues before the release.
This is another regression from the new DWrite technology. The last word in the tooltip is missing! This one is fixed already.
Again, another high DPI issue. You can only notice this one if you look closely. We’ve fixed this already as well.
Fixed already. A lot of people complained about this internally.
This is fixed.
When you try to undock the C# Call Hierarchy toolwindow and drag it away (for example, to another monitor), VS will crash. This one is too embarrassing, because I was the one who is responsible for testing Call Hierarchy. To my defense, I was on vacation when this regressed and when I came back and found this, it was too late to fix. Shell UI team changed something about the WPF toolwindow implementation and we had some layout logic that didn’t expect double.Infinity as an argument, so we crashed. This one’s already fixed in recent builds.
This also only reproes under 120 DPI and above. You can’t resize the two panes below by dragging the vertical bar:
And again, this is one that I should have caught and missed. When I caught this, it was too late to fix for Beta2. The WPF team is looking at this one right now.
Well, guess what, the TFS client team has done it again! TFS HTTPS story was broken in Beta1, and it still has a bug in Beta2. However the good news is that there is a really easy workaround this time.
When adding a new TFS HTTPS webserver (e.g. a Codeplex server at http://codeplex.com), after entering your credentials you will see this:
Don’t panic! Just enter your credentials again and things will work just fine. If you used the Tip (http://blogs.msdn.com/kirillosenkov/archive/2009/09/27/tip-don-t-enter-your-codeplex-credentials-every-time.aspx), then you will be unaffected by this and things will hopefully run smoothly.
Ctrl+Alt+Down used to bring up the active document list, in Beta2 it doesn’t. This is fixed.
Also the scrollbar thumb only moves in discrete steps. The Shell UI team decided not to fix this, because they don’t have time and resources for this. I actually was surprised to discover that the scrollbar didn’t work in 2008 either. Never noticed this until recently.
This one will be fixed as well.
Jeffrey Richter told me about this minor annoyance. Although our language service correctly reports the inferred type when you hover the mouse cursor over ‘var’ in design time, it doesn’t work in debug mode. Since Jeff teaches a lot of courses in debugging and threading, this was bugging him ever since we shipped C# 3.0. Well, we finally fixed it for 2010 RTM. Thanks to Jeff for reporting this!
A while back I’ve logged a bug against the Shell team to “just start VS maximized for heaven’s sake”. They did the fix, but somehow it didn’t make it into the Beta2 branch. They’ll hopefully fix this for RTM.
Well, these were the ones worth mentioning I guess. Apologies if you run into any of these or any other bugs for that matter. I will keep updating this post with more issues that I find or I think users should be aware of. Please keep in mind that this is an unofficial list.
Please do let us know about any issues you find by submitting a connect bug. If the bug/suggestion/feedback is related to the C# language or IDE, also feel free to let me know directly or leave a comment on this blog. Since I work closely with the VS editor team, it’s worth watching their blog and giving them feedback: http://blogs.msdn.com/vseditor. Also, if you have any feedback about the new text rendering in WPF 4.0 and Visual Studio, the WPF Text team has a blog here: http://blogs.msdn.com/text.
Seeing all those bugs tied to 120 dpi screens that you managed to miss, my first thought is: is Microsoft going to help us prevent making the same mistakes? Or is WPF going to be known in a few years as the technology that prevented the advance of 120 dpi screens :) ?
First thanks for all your creative work and finding all the High DPI issues.
However, please don't tell me you are one of those people who I routinely call bad names, those responsible for automatically maximizing a program. Not all users WANT programs to be auto-maximized. I don't mind it being a user setting but I must say that every time a program does this without my permission it makes me call the person responsible for this names.
Please get them to either "unfix" your "bug" (ugh, HOW could this EVER be called a "bug"), or make it optional.
I have to second Mark's comment. VS should retain the current behavior. Remember exactly where I left it and its last size. If it was 700x1300 set at 300,0 then restore it there. If it was maximized then restore it there but also remember its non-maximized size and location. Pleeeeese.
I just installed beta 2. One thing that is really annoying is the amount of flickering switching between some tool windows. For example, take Solution Explorer and Class View in the same tab group and switch between them. It's awful.
we do have a lot of DPI bugs right now, but those are all due to WPF introducing DWrite and UseLayoutRounding in 4.0. We're still in the process of flushing out these issues in WPF for you, so that you won't need to. You will just use WPF and benefit from the work we're doing now.
Mark and Steven:
Ha ha, no worries. Sorry if I wasn't clear. The bug is actually about maximizing VS THE FIRST TIME IT STARTS AFTER INSTALL. All subsequent times it will continue respecting its last saved position. We're not THAT stupid :-P
this is not supposed to happen. Can you please log a bug at http://connect.microsoft.com/visualstudio/feedback so that we can investigate your configuration? Solution Explorer and Class View are both native UI hosted inside WPF so there might be issues that we haven't discovered yet. However it should work very smoothly in most cases. Hopefully you can report this so that we can investigate a fix.
Thanks for the great feedback!!
There seems to be a major regression in Beta 2 regarding ClearType rendering for white text on a dark background in this build. It appears that the color filtering is not working properly, resulting in color intensity that is far too high.
You can see this in the VS 2010 status bar (or anywhere that has white text on a dark background).
Note that this problem only seems to happen on my desktop PC, not my laptop (both running Windows 7 and VS2010 Beta 2). The only difference I can think of is the display driver; my laptop has a NVIDIA Quadro NVS 140m (NVIDIA 186.94 drivers - WDDM 1.1) and my desktop has an ATI Radeon HD 3850 (ATI 8.7 - WDDM 1.1).
Take a look at this screenshot:
The only thing that I can think of is that possibly hardware acceleration was changed between WPF 3.5 / WPF 4.0 (beta 1) and WPF 4.0 (beta 2).
Багов и проблем еще много
1) При попытке открыть документацию (Ctrl-Alt-F1) в трее на короткое время появляется иконка Microsoft Help Listener и молча исчезает. Документация не появляется
2)Если перенастроить на использование online-документации, то все работает, но там нет возможности создания фильтров на языки программирования (чтобы остались только примеры кода на C#)
3) Проект, который отлично компилировался и работал в VS2008 после конвертации перестал компилироваться и выдает
Warning 1 The command-line for the "ResGen" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "ResGen" into multiple calls with fewer parameters per call.
Error 2 The specified task executable "ResGen.exe" could not be run. The filename or extension is too long
4) Шрифт Consolas 10 немного мелковат, но если поставить zoom в 110%, то все выглядит хорошо. Проблема в том, что каждый новый открываемый документ открывается с zoom 100% и нет возможности настроить zoom по-умолчанию или зафиксировать текущий
5) В проектах Silverlight 3 студия/IntelliSense не препятствует использованию конструкций C# 4.0 (dynamic, etc.) и ругается только на этапе компиляции
6) При наведении мыши на табы вспомогательных окон (solution explorer, properties, etc.) иногда само окно немного ресайзится (т.е. визуально видно, как горизонтальный скрол бар, расположенный непосредственно над табами "подпрыгивает" вверх на несколько пикселей
7) После закрытии solutionа (и создании нового проекта) остались заблокированными (т.е. я не могу их удалить) некоторые сборки, использовавшиеся закрытым solutionом. Пришлось закрывать студию, чтобы их удалить
In Beta 1 there were two things i loved.
1. If you selected a few lines of code there wasn't this standard blue selection color.. it fading from white to blue.
2. IntelliSense scrolled smoothly while typing.
Why have these 2 features been removed from Beta 2?
Oh my god, you managed to spoil the WPF text rendering engine! Now it would also misbehave when DPI changes. Alas, alas. I thought it switched to something Office Word 12 would use for text rendering (and GDI+, for that matter) -- adding/removing extra blank pixels between glyphs to negotiate the grid fitting. :-(
DDEX Providers can't load if they use the Microsoft.VisualStudio.Data.Framework.dll because it is not installed in Beta 2, but it does have a policy file forwarding it to a .Net 4 assembly. That is a big no-no. .Net 2 DDEX providers cannot load a .Net 4 assembly.
When I try to access the 'View' menu in VS 2010 beta 2, the program crashes. It doesn't seem to matter how I access it,click the menu item, mouse over while menus are expanded, Alt-V...
I have uninstalled all add-ins (ReSharper and VisualSVN) but the View menu still crashes. Any suggestions?
to help us diagnose this issue, you can attach the debugger, load symbols and view the call stack.
This article describes how to do it:
You can open a bug on http://connect.microsoft.com/visualstudio/feedback and attach a call stack there.
Hope this helps,
I too am getting the most awful font rendering with 2010 using an ATI 4870
The rendering makes Java IDE font rendering look good.