Dodgy Debugging

In a previous post, I mentioned an obscure ASP.NET issue that had me scratching my head for a while.

In order to track it down, I had to resort some dodgy debugging techniques which I wouldn't call exactly scientific nor particularly complex, but they did help, so thought I'd share.

Basically, the page had many controls, and nested controls within many other containers and the like. The problem was difficult because there was no actual errors being caused and no obvious culprit to the "double request" problem I mentioned in the previous post, so I had to start eliminating sections of the page and sections of controls to see if it fixed the problem, and then start to isolate even further.

Problem was, once you start removing controls, the code behind does not compile, and then you have to start hacking your code behind so your site will compile and run. Once you remove more than a few controls, you need to make some serious changes and end up not really achieving anything by doing so. Ok for relatively simple pages, but a nightmare for complex pages. I wanted a way where I didn't break the code behind, but could easily remove controls from the page to try and isolate the issue.

Enter dodgy debugging.

To do this, I simply wrapped portions of the page in a Panel control and set its visibility to false. This still allowed all the code behind to compile and run fine, but because the visibility of the panel was false, the content within the panel would not be rendered at all.

So basically, portions of the page were wrapped in:

<asp:Panel id="pnl" runat="server" Visible="false">
........
</asp:Panel>

I initially wrapped fairly large sections of the page, then reduced the number of controls within the panel, until I could isolate the control that was causing a double postback to my page.

Once I found the culprit, I fixed the issue and removed all the newly added panels from the page. Good to go.