"Asynchronous Processing=true" and Quickwatch / Watch Issues in VS.Net 2008

Question

I've recently run into an issue when attempting to inspect property values using either Quickwatch or Watch in VS.Net 2008. After some investigation, it transpires that having "Asynchronous Processing=true" on the connection string for SqlConnections (to a MSSQL 2008 server) causes property evaluation to timeout in the debugger, after the first query has seemingly completed successfully.

The following will hopefully shed some light on my issue (N.B. You'll need to change the Data Source name to run this):

Imports System.Data.SqlClient

Public Class Thing
    Private Function DoSqlQuery() As Integer
        Using conn As New SqlConnection("Data Source=MYSERVER;Initial Catalog=master;Integrated Security=SSPI;Asynchronous Processing=true;")
            conn.Open()

            Using cmd As New SqlCommand("SELECT COUNT(*) FROM sys.tables", conn)
                Return DirectCast(cmd.ExecuteScalar(), Integer)
            End Using
        End Using
    End Function

    Public ReadOnly Property Value() As Integer
        Get
            Return DoSqlQuery()
        End Get
    End Property

    Public ReadOnly Property Value2() As Integer
        Get
            Return DoSqlQuery()
        End Get
    End Property

    Public Shared Sub Main()
        Dim t As New Thing
        t = t ' Put a breakpoint here.
    End Sub
End Class

Put a breakpoint on the t = t line, then Quickwatch (or add a Watch), then expand t to view the property values. After a long delay (of around ten to twenty seconds), the expansion completes and only one of the two property values is available - e.g.

Now, if the connection string is changed to either remove Asynchronous Processing=true;, or to change the value of that attribute to false, all is well.

I'd be interested in knowing whether anyone has encountered this issue and can provide a workaround, other than removing the attribute from the connection string.

Thanks.

Answer 1

This appears to have been a bug in Visual Studio 2008 - Whilst it may be of little consolation, it appears to have been resolved in Visual Studio 2010 (and 2012).