On Tuesday I got a call up from a developer that was dealing with an unusual ASP.NET problem and was looking for some help. I am not an expert with ASP.NET at all, but we booted up in a Shared View session to look at the problem (that had been stopping him for the better part of a day or two at that point). He had sub-classed a dropdown list and was trying to use it in his site. The new dropdown list had a read-only property added so that when set it would render as basically a label instead of as a dropdown list. He had validated the behavior of the new control in a separate website but couldn’t get it to work in his website and he had borrowed the code along with some other code from another project that had done a similar thing within our company. I didn’t realize the significance of that fact until later.
We tried every little hack or nuance that I could think of and it got us nowhere. The issue was clear the render method that had been overridden for the control was not getting called, but all the other overridden events were (like OnLoad, OnUnLoad, etc….). Why was that happening that way? We had another sub-classed control (a textbox) that was working correctly which made things even more confusing. So as a last straw I figured we would plug into the new feature with Visual Studio that allows you to step into the .NET Framework code and see what is happening. So we configured our machines using the following instructions/resources – the first link is the most update to date as VS2008 SP1 seems to have added greater support for this feature than which is was launched soon after VS2008 RTM.
Then off we went – before long we were in the ASP.NET code watching as it enumerated the control list and called render on each one of the controls belonging to the page. Surprisingly when we got to the control that was having the problem we saw that instead of calling into our render overload it was calling into a DropDownListAdapter class that was a sub-class of a WebControlAdapter that was been injected into the process and was controlling the rendering of our control. Now knowing where to look we found the adapter class as well as some entries into a ServerStateBrowser file registering the adapter to our custom DropDownList class. This was code given to the developer by the other project. That code was obviously doing things that the developer wasn’t expecting and didn’t understand (neither did I). Obviously there is something to learn there about being wary about taking a lot of code that you probably don’t need and aren’t sure all it does. But all is well that ends well (especially since both he and I wanted this resolved since the New Years holidays started the next day). We could very well still be hunting without the wonderful new tool in the toolbox to reach into the Framework to see what is happening. Next time I will break it out sooner rather than grappling in the dark for as long as we did!