Visual Studio (2010) is not stopping after I close the AvalonDock (Workbench) Window. I have to manually select Debug->Stop Debugging menuitem to get the debugger to stop. I believe this is due to some resource not getting released. Anyone see this before? The difficulty is that I don't see any information as to what is preventing the debugger from Stopping so it's perplexing as to how to debug this issue.

[Added 1-Sep-2010] By unloading projects from the solution, I narrowed down the problem project. It is totally unexpected. The Export of SoapBox.Core.ExtensionPoints.Options.OptionsDialog.View, used to display a custom Options Window, is causing the debugger to not stop. If I comment out the Export line, the debugger correctly stops when the Workspace Window is closed. Can someone explain why and how to fix? Below is the contents of the OptionsDialogView.xaml.vb.

<Export(SoapBox.Core.ExtensionPoints.Options.OptionsDialog.View, GetType(Window))> _
Public Class OptionsDialogView

    Private Sub OK_Click(ByVal sender As Object, ByVal e As RoutedEventArgs)
        Me.DialogResult = True
    End Sub

    Private Sub Cancel_Click(ByVal sender As Object, ByVal e As RoutedEventArgs)
        Me.DialogResult = False
    End Sub

End Class

asked 31 Aug '10, 09:46

BSalita's gravatar image

accept rate: 22%

edited 11 Sep '10, 16:13

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦

Shouldn't the class be declared Partial and inherit from Window? At any rate, in your custom options dialog, do your Ok and Cancel buttons include the IsDefault=True and IsCancel=True properties in their declarations?

(01 Sep '10, 12:41) Scott Whitlock ♦♦

More info. Partial and Inherit not necessary. Closing, Deactivated, Closed, Unloaded events in codebehind NEVER executed UNLESS the options window is used once in which case the debugger stops. This all seems to suggest that the issue is that the Window is not being closed when Workspace Window closes.

(01 Sep '10, 13:26) BSalita

If I do an explicit close of OptionsDialog windows, the debugger stops. I'm wondering if the issue is that OptionsDialog shouldn't be opened until a ShowDialog is done?

<importmany(soapbox.core.extensionpoints.options.optionsdialog.view, gettype(""> _ Private Property optionsDialogView As List(Of System.Windows.Window)

Public Sub LayoutUnloading(ByVal sender As Object, ByVal e As EventArgs)
    For Each w As System.Windows.Window In optionsDialogView
End Sub
(01 Sep '10, 13:51) BSalita

I may have found an issue in SoapBox.Core.Options.ToolsMenuOptions. Because the ImportMany doesn't use Lazy, it opens all OptionsDialog windows but never closes them. Thus if an OptionsDialog ExtensionPoint is used, the window will never be closed causing the debugger to hang. I recommend these changes to SoapBox.Core.Options.ToolsMenuOptions.


[ImportMany(ExtensionPoints.Options.OptionsDialog.View, typeof(Lazy<Window>), AllowRecomposition = true)] // Not sure if AllowRecomposition = true is necessary
private IEnumerable<Lazy<Window>> optionsDialogView { get; set; }

protected override void Run()
    Window tmpView = null;
    foreach (Lazy<Window> view in optionsDialogView)
        tmpView = view.Value;



answered 01 Sep '10, 14:14

BSalita's gravatar image

accept rate: 22%

edited 01 Sep '10, 14:17

That's good. Consider it done! (I'm surprised that just instantiating a Window instance causes this to happen.)

(01 Sep '10, 18:22) Scott Whitlock ♦♦

So this change is no longer needed if we do this ( right?

(11 Sep '10, 14:38) Scott Whitlock ♦♦

Right, changes-to-options-menu-processing supersedes this change request. It fixes this and other issues by use of Lazy and IWindowFactory.

(11 Sep '10, 15:51) BSalita

It's a long shot, but you don't still have a reference to System.ComponentModel.Composition.dll hanging around, do you?


answered 31 Aug '10, 20:54

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦
accept rate: 50%

Yes, but why are you asking? Any MEF dll needs System.ComponentModel.Composition.dll .Net 4 to specify Import and Export attributes. Should these disappear from the process when the Workspace Window is closed? What's a good way of checking which Dlls are still loaded?

(01 Sep '10, 08:07) BSalita

All dlls are still shown in the Modules window after Workspace Window is closed. SoapBox.Core.Host.exe is still running. The issue is why is it still running after Workspace Window has been closed? How to troubleshoot this situation?

(01 Sep '10, 08:20) BSalita

@BSalita: Sorry, I meant that under VS2008 we were using an external reference to that DLL in the references folder, but under VS2010, it's included in .NET 4. During the upgrade, if you don't delete that old DLL from the bin directory, I'm not sure what might happen.

(01 Sep '10, 12:29) Scott Whitlock ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 31 Aug '10, 09:46

Seen: 8,212 times

Last updated: 11 Sep '10, 16:13

powered by OSQA