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.