Rob's Blog

The LINQ to SQL Visualizer is a phenomenal tool.  This is how debugging should be done.  Scott Guthrie introduced it in the Visual Studio 2008 Beta 2 timeframe, and I've been hooked ever since.  It's now bundled in the Visual Studio 2008 RTM samples, though it's not installed by default.  Instructions of how to install it are here.

Well, I'm splunking along in some code that happens to be in a transaction.  I've just inserted a row, and I'm about to execute the select that refreshes the business object with generated content including the primary key.  I open up the Visualizer, and push the Execute button.  Nothing happens, and the window freezes.

It dawns on me that the unit test's transaction has locked the row in question, and the Visualizer can't get to it.  Well, that's all fine and good, but why wouldn't it be in the same transaction and/or join the transaction and/or create a rollback point in the transaction in process so the "execute" button can be undone once the window is closed?

I emailed Scott Gu, and he passed on my question.  (Scott is phenomenally awesome with email, by the way.  I can only imagine how many emails he gets from users across the globe, and each time I email, I get a personal response.  I hope I can be that awesome when I grow up and get an office with a window.)  The answer came from a tech that Visualizers don't use the same app domain as Visual Studio, so reusing the connection was impossible, making subscribing to the transaction also impossible.

Since this is sample code, and thus the code is provided, I'd like to take a stab on an off hour changing the sample to store the SqlConnection (or IDbConnection) rather than the ConnectionString and see if it works.  I expect it won't, but if it did, wouldn't it be cool?

In the mean time, I'll just remember to look in the LINQ to SQL Visualizer but not execute if I'm inside a transaction.  If I'm that curious, I'll grab the query, finish the transaction, and execute it inside Sql Management Studio or LinqPad.

Rob

For ages I've wanted to be able to put a comment of some kind in my code that I could get to come up during a build.  "Hey, you haven't finished this" or "This is an assumption we need to run by the suits" or "you dork, how could you even think to do it this way" or similar -- notes to myself and others that there is work left to be done here.

Well, after trying unsuccessfully to look towards subclassing or hacking the Obsolete attribute the answer was handed to me:

1. I build comments in the form // TODO: or // ASSUME: or // BROKEN: or similar, I choose the View menu, and choose Task List.  Ok, granted, that's been there since the beginning of time, but who put that there and why didn't they tell me?  Holy cow, that's cool.  I can even configure it with my own set of commentaries like // DORK_MOVE: or // INSECURE: or // WHAT_WERE_YOU_THINKING:

2. There's a pre-processor directive called # warning.  Put what ever message you want after, and it shows up in the normal error list.

With these two tools now in the arsenal, I can capture my thoughts in the place most relevant to the task at hand -- in the code.  And I can be reminded of them in the place most relevant to the task at hand -- the next tab over from the build output window.  Very nice.

Rob