title: How to do SQL Server 2k8 with VS2010 CLR debugging
body: <p>Tearing my hair out in despair now after hours of fighting and googling. I'm trying to debug a simple CLR method. Setup: Visual Studio 2010, SQL Server 2008 R2 Express, Vista Business SP2. I'm a domain user but a local admin on the machine, and a sysadmin on the local instance of SQL Server. I created a new VS database project, pointed it to my db connection string (used this db before), then it asked me if I want to enable debuggig for the connection, to which I answered yes.</p>
  
  <p>I verified that the project deploys fine (can see the assembly and its procedure appear in SQL Server Management Studio), and that I can call it just fine within SSMS. I then added the very same <code>EXEC</code> code to the <code>Test.sql</code> script in my db project, and marked it as the default debug script. I then set a breakpoint both in <code>Test.sql</code> and CLR code.</p>
  
  <p>But when I hit F5 all I get is the following output:</p>
  
  <pre><code>Canceled by user.
  Auto-attach to process '[2144] sqlservr.exe' on machine 'DAWID-PC' succeeded.
  The thread 'dawid-pc\sqlexpress [54]' (0x13c4) has exited with code 0 (0x0).
  The thread 'dawid-pc\sqlexpress [54]' (0x13c4) has exited with code 0 (0x0).
  The thread 'dawid-pc\sqlexpress [56]' (0x109c) has exited with code 0 (0x0).
  The thread 'dawid-pc\sqlexpress [56]' (0x109c) has exited with code 0 (0x0).
  The program '[2144] sqlservr.exe: dawid-pc\sqlexpress' has exited with code 0 (0x0).
  </code></pre>
  
  <p>And my debugging session ends right there. </p>
  
  <p>I have <code>c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe</code> running; I can see a message saying <code>MyDomain\MyUsername connected.</code> appear every time I hit F5 in Visual Studio. I don't have a firewall running on my PC, and have no anti virus software installed. </p>
  
  <p>Do you have any idea how to make it work? My real target was remote debugging but I thought I should try local first and iron out any setup quirks before venturing any further...</p>