In my blog entry from about a month and a half ago, I summarized my finding on using Visual Studio 2010 with SQLCLR, and the partial support of SQL Server 2008 new features. One feature (with the disclaimer that's it's not preferred/supported) that I thought I'd lost was "attach to process" style debugging with SQLCLR. And that I hadn't discovered the "secret sauce" that makes this work. Here's the secret sauce.

Robert Bruckner's blog entry (about debugging SSRS add-ins) mentions that "there are now two debug engines inside Visual Studio 2010, one for .NET 2.0/3.0/3.5, and the other for 4.0 only". To debug SQLCLR  (which uses .NET 2.0/3.5) with "attach to process" we need a config file like the one Robert posted for reporting services. Except that we're attaching to sqlservr.exe. So the file must be called sqlservr.exe.config and be in the same directory as sqlservr.exe.

Then "attach to process" works with SQLCLR code (as I said, I started using this for SQLCLR broker activation procedures). The only odd thing is that I had to "attach to process", run program that hits SQLCLR, it hangs. Detach from process, cancel program, try attach and run program that hits the SQLCLR again. Then it worked a treat. Thanks, Robert. Do read the warning that appears when you debug this way. On occasion, if things get really hosed in debugging (or I do something strange in VS), I've been able to knock down sqlservr.exe debugging like this. So I only use this on the private copy of SQL Server at my own desk.

Last week I was at TechEd in New Orleans, presenting, manning the SQL Server Security and Managability station, meeting with friends and business associates, and, of course, partying. The heat and humidity took a little getting used to, but otherwise it was a great time. Thanks to everyone who attended the sessions; the demos are posted on the SQLskills website as promised. To all of my old friends, as well as the new friends I met in New Orleans for the first time, I hope you enjoyed it as much as I did.