The extension can be found in the Visual Studio Gallery and on Codeplex.

In this forum thread (warning: Dutch) someone was complaining that it’s not really easy to export the contents of the Locals debug window to a XML file. I’ve neved had the need for that myself but I thought, it can’t be that hard. Turns out it isn’t.

I’ve written a VS2010 add-in that adds a menu item to the Tools menu in Visual Studio that will export all the locals for the current stack frame and open the XML file in Visual Studio. As always a picture says more than a thousand words so see for yourself:

A program in debug mode, notice the Locals window in the left bottom:

Export the locals via the menu option:

The exported XML document is opened in Visual Studio:

For now it will export to 2 levels deep, any more than that will make it incredibly slow.

Downloads:

The VSIX can be downloaded here: ExportLocals.vsix

The sources can be downloaded here: ExportLocals.zip

Or you can install the add in via the Visual Studio Gallery

One slight problem I’ve discovered is that the C# types we use in the ReceiveRequest activity are generated from a custom XSD and the WSDL generated by the workflow service doesn’t reference that schema but generates a new one. Normally this isn’t that much of a problem, simply create a custom WSDL and set the externalMetadataLocation option in the web.config:

<behavior name="MyServiceBehavior">
   <serviceDebug includeExceptionDetailInFaults="true" />
   <serviceMetadata httpGetEnabled="true" externalMetadataLocation="../MyService.wsdl" />
</behavior>

Contrary to popular belief, this doesn’t work! The workflow service still gives it’s WSDL as being MyService.xamlx?wsdl instead of the custom WSDL. After some Google-ing (is that a word?) I found that there was something missing: a binding. More specific: a mexHttpBinding. It seems that without specifying the Metadata Exchange the workflow service will continue to provide it’s own idea of the WSDL and ignores the WSDL specified in the externalMetadataLocation.

Fortunately the fix is easy. Add a new endpoint to the service configuration that uses the mexHttpBinding:

<service name="MyService" behaviorConfiguration="MyServiceBehavior">
   <endpoint binding="mexHttpBinding" contract="IMetadataExchange" address="mex" />
</service>

After adding this and refreshing the workflow service in the browser it now correctly shows the custom WSDL!

To find out what the real problem was I’ve built a test application that basically does the same thing as the complex window that is giving me such a headache. So here goes:

I have a class like this:

public class Base {
    public string Property1 { get; set; }
    public Sub SubItem { get; set; }

    public Base() {
        Property1 = "Base Property1";
        SubItem = new Sub();
}
public class Sub {
    public string Property1 { get; set; }

    public Sub() {
        Property1 = "Sub Property1";
    }
}

Which is bound to a TextBox:

private void buttonBind_Click(object sender, EventArgs e) {
    Base b = new Base();

    // This works
    textBox1.DataBindings.Add("Text", b.SubItem, "Property1");

    // This doesn't work
    textBox2.DataBindings.Add("Text", b, "SubItem.Property1");
}

Now the first binding will work but the second one will throw a TargetException. I have no clue why this happens but the message of the exception and the stack trace give some hints that this is a reflection problem. However the binding specifies to bind a string property to a string property so that shouldn’t be a problem.

A workaround for this problem is to use a BindingSource:

private void buttonBind_Click(object sender, EventArgs e) {
    Base b = new Base();
    BindingSource bs = new BindingSource(b, null); // Use a empty datamember

    // Now it will work
    textBox2.DataBindings.Add("Text", bs, "SubItem.Property1");
}

But it’s quite a lot of work to replace this in the current application so I hope this gets fixed soon.

In the meanwhile I’ve filed a bug report at Microsoft Connect (see here) with sample code that demonstrates the behavior so you can test for yourself. If you do, please vote on Microsoft Connect to get it under their attention!