locked
Window configuration persistence issues in VS 2010/2012 RRS feed

  • Question

  • I'm trying to save window layouts via DTE.WindowConfigurations.Add and restore them via DTE.WindowConfiguration.Apply.

    This works fine in VS 2008, but in VS 2010/2012 I see that the window configuration is available until I restart Visual Studio, and then the window configuration seems to be gone.

    Easiest way to repro interactively:

    • Install the Microsoft PowerConsole extension, this is a dependency of the IronPython console extension (http://visualstudiogallery.msdn.microsoft.com/67620d8c-93dd-4e57-aa86-c9404acbd7b3).
    • Install the Microsoft IronPython IronRuby console extension (http://visualstudiogallery.msdn.microsoft.com/777407db-348b-4ac6-8106-ce4da1bd3bd2).
    • Start Visual Studio, start Power Console via View | Other Windows | Power Console.  Select IronPython from the "Switch Console" dropdown in the toolbar.
    • Enter this code:
    import clr
    clr.AddReference("EnvDTE")
    from EnvDTE import WindowConfigurations
    WindowConfigurations.Add(dte.WindowConfigurations, "Test 1")
    for cfg in dte.WindowConfigurations: print cfg.Name
    • Note configurations are listed for Design, Debug, NoToolWin, and Test 1.
    • Restart Visual Studio.
    • Enter this code in Visual Studio IronPython console:
    import clr
    clr.AddReference("EnvDTE")
    from EnvDTE import WindowConfigurations
    cfg = WindowConfigurations.Item(dte.WindowConfigurations, "Test 1")
    for cfg in dte.WindowConfigurations: print cfg.Name
    • Note that the last two lines result in errors "The 'Test 1' window configuration does not exist."
    Is there a way to get this to work in VS 2010/2012?
    • Edited by ewells Monday, December 17, 2012 7:31 PM Added detail
    Monday, December 17, 2012 7:30 PM

Answers

  • Try calling Apply on the WindowConfiguration after creating it. Seems like a regression (the entire window manager was re-written in 2010). It looks like when you create a profile it copies the currently active profile to form the base of the new profile. The profile cache also remembers the name, however it only saves profiles when they become activated. So what happens without Apply is that we save the name and on the next run if you use a foreach over WindowConfigurations we attempt to retrieve the profile with the name 'Test1', that returns null because the actual profile wasn't saved, and we throw an ArgumentException inside the anonymous method in the callstack you have above.

    I can file a bug when I get back to work (on vacation at the moment), but calling Apply after creating it (or really any time) 'fixes' it, I don't think it would be problematic to do so in 2008, but you would have to test that.

    Ryan

    • Marked as answer by ewells Friday, December 21, 2012 11:26 PM
    Friday, December 21, 2012 10:33 PM
  • I believe the serialized window layouts are kept in .winprf files under your <user>\AppData folder somewhere (mine are <user>\AppData\Roaming\Microsoft\VisualStudio\11.0). It looks like there is also a windows.index file in the same location that is where the profile cache is getting the information about names and associated .winprf files. You could probably open it up (it is just a plain text file) and delete all the ones other than Debug Design NoToolWin and delete any .winprf files that don't start with Debug/Design/NoToolWin and you would be 'back to square 1'.

    Ryan




    Friday, December 21, 2012 11:37 PM

All replies

  • Hi Ewells,

    I installed them in my computer and try these codes in IronPython console. I got the list:

    NoToolWin

    Design

    Test 1

    I didn't get the errors as you said. I couldn't reproduce this issue in my computer.

    Btw, I tried it in Visual Studio 2010 ultimate.

    Best regards,


    Ego [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, December 19, 2012 2:52 AM
  • Just want to confirm, you restarted Visual Studio in between?  I've tried these steps on four different computers, all four reproduced the same way.
    Thursday, December 20, 2012 8:55 PM
  • Hi Ewells,

    Yes, when I restart the Visual Studio it was reported:

    The 'Test 1' window configuration does not exist.

    Sorry for my carelessness.

    I create an add-in to print the WindowConfigurations as the article said:

    http://msdn.microsoft.com/en-us/library/envdte.windowconfigurations.aspx

    I can't get the same result.

    So I think may be there are something wrong in this tool, it doesn't clean the data after close the Visual Studio.

    Best regards,


    Ego [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, December 21, 2012 5:48 AM
  • When you say this tool, which tool are you referring to?  The Python console?  That seems unlikely to me, the script is simply calling automation APIs.

    One difference between my snippet and the snippet you referred to is that it used Count/Item instead of the enumerator.  That would be equivalent to this Python code:

    import clr
    clr.AddReference("EnvDTE")
    from EnvDTE import WindowConfigurations
    cfgCount = WindowConfigurations.Count.GetValue(dte.WindowConfigurations)
    for i in xrange(1, cfgCount + 1): print WindowConfigurations.Item(dte.WindowConfigurations, i).Name

    This reproduces the same error.

    I also tried running the code in a C# package to double-check, this resulted in a System.ArgumentException, the message was "The 'Test 1' window configuration does not exist."  The stack trace was:

       at Microsoft.VisualStudio.Platform.WindowManagement.DTE.WindowConfigurations.<>c__DisplayClassa.<EnvDTE.WindowConfigurations.Item>b__9()
       at Microsoft.VisualStudio.Shell.ThreadHelper.Invoke[TResult](Func`1 method)
       at Microsoft.VisualStudio.Platform.WindowManagement.DTE.WindowConfigurations.EnvDTE.WindowConfigurations.Item(Object index)
    Friday, December 21, 2012 5:17 PM
  • Try calling Apply on the WindowConfiguration after creating it. Seems like a regression (the entire window manager was re-written in 2010). It looks like when you create a profile it copies the currently active profile to form the base of the new profile. The profile cache also remembers the name, however it only saves profiles when they become activated. So what happens without Apply is that we save the name and on the next run if you use a foreach over WindowConfigurations we attempt to retrieve the profile with the name 'Test1', that returns null because the actual profile wasn't saved, and we throw an ArgumentException inside the anonymous method in the callstack you have above.

    I can file a bug when I get back to work (on vacation at the moment), but calling Apply after creating it (or really any time) 'fixes' it, I don't think it would be problematic to do so in 2008, but you would have to test that.

    Ryan

    • Marked as answer by ewells Friday, December 21, 2012 11:26 PM
    Friday, December 21, 2012 10:33 PM
  • Thanks for the answer Ryan, especially while you're on vacation.  I tried this and it looks like this fixed my issue.

    One other quick question, is there a way I can clear out old window configurations that Visual Studio remembered but now throws on because I didn't call Apply when saving the window configuration?  Like some registry keys or files under appdata I can delete?  I currently have about 4 dozen stale window configurations that Visual Studio is throwing on from where I was testing trying to find a way around this. :-)

    Friday, December 21, 2012 11:25 PM
  • I believe the serialized window layouts are kept in .winprf files under your <user>\AppData folder somewhere (mine are <user>\AppData\Roaming\Microsoft\VisualStudio\11.0). It looks like there is also a windows.index file in the same location that is where the profile cache is getting the information about names and associated .winprf files. You could probably open it up (it is just a plain text file) and delete all the ones other than Debug Design NoToolWin and delete any .winprf files that don't start with Debug/Design/NoToolWin and you would be 'back to square 1'.

    Ryan




    Friday, December 21, 2012 11:37 PM
  • That worked great, thanks again for the help.
    Friday, December 21, 2012 11:48 PM