- What are my cookie values?
- What are all the items I have in a current session?
- How can I know how much ViewState is on a page?
- For the last request I made, how many times did I call a particular method?
As an ASP.Net developer, these are constant questions that I run into while developing. In a conversation with a co-worker, he suggested that the application should have a “developer’s toolbar”, that could get displayed as needed on a page to answer some of these questions? What a great idea. But how do I go about it, so that it isn’t part of my production code? What are my options?
- Use compilation constants to remove the code as it is released. I try to stay as far away from compilation constants as possible. Too many bad experiences.
- Use a configuration setting. This might be an option. However, this feels like putting development code into production.
- Create a HttpModule or HttpHandler. I have never written one of these, but some reading indicates that it might be possible.
In the end, I chose the HttpModule / Handler route. Here is the story for it.
Creating the HttpModule
First I started by creating a new class library and adding a new class that implements IHttpModule. I then hooked into the following events:
I used this event to tackle the issue of deciding whether or not to show the toolbar. This was challenging for me because I used a Session and a QueryString to determine this for me. The reason for this is I wanted the toolbar to be off by default, in case the web.config file included the HttpModule and went to production. Second, I wanted a way that the developer at any time could show the toolbar or hide it.
This event is the first time that the developer gets access to Session data in the pipeline for an HttpModule. For the longest time, I was getting errors and couldn’t understand why I couldn’t read or write to the session. I added the following interface IRequiresSessionState to the class and this solved my problems.
Here is the code that I used to check if the toolbar should be available.
If the toolbar should be visible, the code to create the toolbar is implemented.
Notice a couple of things with this code. First I created custom handler classes for items like cookies, logs, and sessions. I placed them in the same assembly as the HttpModule so that I could create kind of a package deal. After the standard web.config entries for handlers and modules, this code is in a working state, but not where I want it to be. That is where the BeginRequest and a custom Filter came in.
Here is the result of the toolbar at the bottom of the page
I used the BeginRequest event to set the Response.Filter equal to a custom filter. The reason for this only became evident when I looked at the view source on a page.
This is what it looked like before the filter:
Here is after the filter.
Notice how the toolbar itself was originally after the end html tag. This is because I am writing to the Response.Output method the toolbar. In the HttpModule when making Response.Write calls, they are placed at the end of the stream of the page. In another post, I will look at the Response.Filter and how I used that.