Update 3 RC 2 bug: using the Windows 7 jump-list to open a VS project shows the "error list" window while loading even though the error list was not visible when previously closing VS - by StartedWithDOS

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 789468 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 6/4/2013 7:42:23 AM
Access Restriction Public

Description

Starting with Update 3 RC 2 (did not happen in RC 1), have VS 2012 pinned to the taskbar.  Right-click the icon to use the "jump-list" and select a project to open with Visual Studio.  While VS is loading it will show the "error list" window even if this window was not previously showing when you closed VS.  Also, while the error list is showing, VS won't repaint that area, so the Windows desktop shows through.  When VS has loaded the project, it will close the error list window.

This is a new bug introduced in Update 3 RC 2.
Sign in to post a comment.
Posted by Deon [MSFT] on 4/29/2014 at 12:21 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by StartedWithDOS on 6/8/2013 at 8:10 AM
Alin,

Thank you very much for the detailed, professional response. You are correct. I had recently (approx. a couple of days before upgrading to RC2 of update 3) double-clicked a C# file in Windows Explorer which opened in VS of course. I actually try hard to avoid doing that by habit...since tradtionally opening VS for viewing 1 file isn't worth the slow loading of VS, but this time it was an accident. I usually right-click and open with Notepad++. Maybe one day VS will be so light that you can open a single file with the same speed as notepad.

I followed your steps, and yes, the Error List window was indeed showing when I opened a single file again. I closed the window, then closed VS. Now the problem is gone. What's interesting is, when I did accidentally open the file the first time, I'm almost positive I did not explicitely open the Error List window. So, I'm wondering if the bug is this: have error-list window open in a normal VS project session and either (1) open another copy of VS by opening a file in Windows Explorer, OR (2) have Error list window open in normal project session, close VS leaving error-list window open, then open a single file using Windows Explorer.

Anyway, thanks a lot for responding quickly.
Posted by Alin Constantin - MSFT on 6/7/2013 at 2:25 PM
Hi Dean,

We have analyzed what causes the NoToolWin window layout to change and contain toolwindows visible unintentionally.
This is not a regression in VS2012 RC2. It has been like this for a couple of versions and I can reproduce the same problem with VS 2010.

The NoToolWin layout is intended to be a window layout without any tool windows visible, and is used by VS when opening a file, project or solution by double clicking the item in Windows Explorer (or selecting in StartMenu's RecentItems, taskbar's JumpLists, etc). The intent of the empty layout is to start Visual Studio fast, and not spend time loading packages and initializing toolwindows that you don't use (especially in the case of editing a file).
In the case of opening a project or solution, when the project/solution is loaded, Visual Studio will apply the Design window layout.

What probably happened is that at some point you opened in Visual Studio a file from WindowsExplorer (which set the NoToolWin layout), brought into view a couple of toolwindows (e.g. Error List), then opened a project or closed Visual Studio.
This saved the NoToolWin layout containing the tool windows made visible. And now, every time you open a project file from recent items or Windows Explorer you see those toolwindows while the NoToolWin profile is temporarily applied.

A solution on fixing the layout (beside the hack of deleting the NoToolWin*.winprf file) is:
- Open Windows Explorer and locate a file that can be open in Visual Studio (cs, cpp, vb file, etc)
- Double click the file or right click it and choose OpenWith...Visual Studio 2012. This should launch Visual Studio with the file open, and those extra toolwindows like Error List will also be visible.
- Close the Error List or any other toolwindows that may be visible
- Close Visual Studio, and the NoToolWin layout will be saved empty again
Now you should be able to open projects from jumplists and the empty layout will be applied temporarily until the project is opened.

For the next Visual Studio version we will be looking into preventing changes to the NoToolWin layout, but until then you should avoid bringing toolwindows into view while editing files opened directly from Windows Explorer.

Thank you,
Alin Constantin
[Visual Studio IDE Experience development]
Posted by Alin Constantin - MSFT on 6/7/2013 at 12:41 AM
Sorry for the multiple similar comments, the Connect site kept displaying error messages claiming it failed to post due to message length, while in the same time posting the message....

Alin
Posted by Alin [MSFT] on 6/7/2013 at 12:37 AM
The problem you're experiencing is due to a corrupt windows layout file - it was supposed to have no toolwindows visible, yet somehow it contains windows like ErrorList.
The intent when opening a project from context menu is to start the IDE fast, with no toolwindows visible while we're loading the project, then apply the final window layout once the project has completed loading.
Posted by Alin [MSFT] on 6/7/2013 at 12:37 AM
Hi StartedWithDOS,

The problem you're experiencing is due to a corrupt windows layout file - it was supposed to have no toolwindows visible, yet somehow it contains windows like ErrorList.
The intent when opening a project from context menu is to start the IDE fast, with no toolwindows visible while we're loading the project, then apply the final window layout once the project has completed loading.

While we're still investigating how this file was incorrectly generated, I believe you can use this quick fix: look in the %AppData%\Microsoft\VisualStudio\11.0 folder for a winprf file with name starting with "NoToolWin", it will looks something like NoToolWin_ttsb2rez.u54.winprf. Rename or delete this file, and it will be re-created next time you open a solution from context menus or by double clicking in Windows Explorer, and this time it should be created correctly, with no toolwindows visible.

Alin Constantin
[Visual Studio IDE Experience Development]
Posted by Microsoft on 6/5/2013 at 12:29 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Macy [MSFT] on 6/4/2013 at 7:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)