Dzisiaj chciałem podzielić się sztuczką, jak można automatycznie podpiąć się do procesu. Pracując nad aplikacjami webowymi mamy często potrzebę przedebugowania procesu iis, bądź jakiegoś napisanego przez nas plugina, np. Silverlight. Można to ręcznie zrobić poprzez okiekno Attach to process. Jednak na dłuższą metę jest to strasznie niewygodne i czasochłonne.

Na pomoc mogą nam przyjsć makra dostepne w VS. Poniżej przedstawiam kod, który umożliwia podpięcie się do iis i przeglądarki chrome. Należy otworzyć sobie edytor makr i go tam wkleić.

Ja mam ponadto zdefiniowany skróty klawiszone, odpowiednio Ctrl+1 i Ctrl+2

Public Module Attach
    Sub AttachToChrome()
        AttachTo("chrome.exe", "Silverlight")
    End Sub

    Sub AttachToIIS()
        AttachTo("w3wp.exe", "Managed (v4.0)")
    End Sub

    Sub AttachTo(ByVal name As String, ByVal engine As String)
        Try
            Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger
            Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default")
            Dim dbgeng(1) As EnvDTE80.Engine
            dbgeng(0) = trans.Engines.Item(engine)

            For Each p As EnvDTE80.Process2 In dbg2.GetProcesses(trans, "localhost")
                If p.Name.EndsWith(name) And Not p.IsBeingDebugged Then
                    p.Attach2(dbgeng)
                End If
            Next

        Catch ex As System.Exception
            MsgBox(ex.Message)
        End Try

    End Sub

End Module

Recently I was investigating strange memory leaks in Silverlight application. After switching back and forth through the screens the memory was gradually growing. Because of the lack of silverlight profiler I used windbg to diagnose the problem. It turned out that none of the view models and controls were released.

After several hours of digging I found that the problem was the behaviors and triggers from Blend samples (Expression.Samples.Interactivity). If you remove controls that use some of the behaviors or trigger actions (these which subscribe internally on events) you’re in trouble. The memory used by them is never released. If your application is small there is probably no problem. However if you’re developing more complicated ones with lot of screens that have to work for several hours the memory consumption can be unacceptable.

The solution

Here is the workaround I used to correct this situation. Before removing any control you should detach all triggers and behaviors.

static void UnwireBehaviors(object current)
{
    DependencyObject parent = current as DependencyObject;

    if (parent != null)
    {
        Interaction.GetTriggers(parent).Clear();
        Interaction.GetBehaviors(parent).Clear();

        for (int i = 0; i < VisualTreeHelper.GetChildrenCount(parent); i++)
        {
            var child = VisualTreeHelper.GetChild(parent, i);
            UnwireBehaviors(child);
        }
    }
}

However it's not all. There is a couple of bugs in the code from codeplex too. The class BindingListener doesn't call Detach on it's internal structures and doesn't wire events in some cases. The corrected code should look something like this:

public class BindingListener 
{
    [...]
    private void Detach() 
    {
        if (this.listener != null)
        {
            this.listener.Detach(); // This is not called in the original samples
            this.ReturnListener();
        }
    }

    private DependencyPropertyListener GetListener() 
    {
        DependencyPropertyListener listener;

        if (BindingListener.freeListeners.Count != 0) 
        {
            listener = BindingListener.freeListeners[BindingListener.freeListeners.Count - 1];
            BindingListener.freeListeners.RemoveAt(BindingListener.freeListeners.Count - 1);

            // return listener; This was called in the original samples preventing event wiring  
        }
        else
            listener = new DependencyPropertyListener();

        listener.Changed += this.HandleValueChanged;

        return listener;
    }

    [...]
}

Visual Studio Debugger provides a couple of pseudovariables which can be used in a watch window during managed debugging session (C#, J#, VB):

$exception – contains information on the current exception.

$user – contains several information about the user running the application.

The are several more if you’re debugging native code, see documentation for details.