Monthly Archives: June 2011

Glimpse 0.83 Released!

We know its been a long time coming but Glimpse 0.83 is finally up and ready to go.

We have a bunch of fixes and features in this build including the infamous 404 fix and a heap of other changes, some of which are listed below:

  • Switch from /Glimpse/Config to /glimpse.axd, including temporary automatic redirect and warning message
  • Notification on at top of screen when Glimpse is turned on
  • Glimpse/glimpseClient.js has been shifted to /Glimpse.axd?r=client.js to support certain server configurations
  • Glimpse/glimpseSprite has been shifted to /Glimpse.axd?r=sprite.png to support certain server configurations
  • Added a bunch of new fields to the Environment tab and re-arranged the layout
  • Added application/json as a default content type
  • Simple fix for a bug where ajax requests can occur before Glimpse is rendered
  • Shifting placement of expand/collapse data icon in the UI
  • Changed font of text in Glimpse panel to something more readable
  • Made IGlimpsePlugin implementations more testable by replacing HttpApplication with HttpContextBase
  • Introduction of logging – … – used for debugging glimpse
  • Fixed bug with users in non en-Us cultures
  • Fixed issue some users were getting with PowerShell install file
  • Vastly improved Glimpse documentation (with more on the way!), HUGE thanks @hahndorf

To update simply head over to or

Also, keep an eye out for the automatic update notifier that we have built into the Glimpse UI that will tell you when an update is available. This was released with Glimpse 0.82 but this will be the first time it is able to be used.

Note, we also are officially providing a copy of the Glimpse dll’s on Codeplex for people not using Nuget –

Please give us feedback and let us know how it goes! Thanks again for all your support.

404 errors fixed! Goodbye /Glimpse/Config, hello /Glimpse.axd

The short version, is that /Glimpse/Config is being deprecated and being replaced with /Glimpse.axd.

The back story is kind of interesting and we thought we would share what we found with you… needless to say we learn’t a lot about Http Modules/Handlers and how it all comes together.

One of the things I loved so much about Glimpse was the /Glimpse/Config URL. To me this approach seemed so clean and simple, and very web 2.0 ish. However, when we went with this approach we failed to realize some of the gotchas that we ran. The approach we took has led to a number of people experiencing 404 errors in a number of different cases.


I guess when you first start creating something you fail to realize the full extent that something will be used. Our methodology to date has been to not over-engineer, develop for the known with a close eye on the future and to get working code into peoples hands. Given this philosophy and the way Glimpse came about, its not entirety surprising that we didn’t catch every possible case out there.

Problem 1
Specifically the technique we used to register our HttpModule, and thus implement clean URL’s, was by using DynamicModuleUtility (see more here – DynamicModuleUtility – a great article by K. Scott Allen). When we originally saw this we thought that this would be a simple way of wiring Glimpse up. Even though NuGet supply’s support for web.config transforms, we wanted to limit the amount we changed to as little as possible. DynamicModuleUtility offered config free HttpModule wire up.

At the time when we took this approach, we knew that this feature was only made possible by taking a dependency on the Microsoft.Web.Infrastructure assembly. But months later when we wanted to support Web Forms, this dependency is something that we didn’t take into account. During testing this problem never arose, as all our test environments also had ASP.NET MVC installed. This obviously presented a problem for people using Glimpse who didn’t have ASP.NET MVC installed.

Problem 2
Another issue arose as a side effect of using DynamicModuleUtility (even for some people that where running MVC sites and hence had the Microsoft.Web.Infrastructure assembly), was the missing runAllManagedModulesForAllRequests attribute from their config. As it turns out, the DynamicModuleUtility.RegisterModule() method registers the Glimpse module as a managed module. If the runAllManagedModulesForAllRequests isn’t set to true, then the module doesn’t get called for .js requests, which leads to another possible 404.

This is also true for web forms site, as the .NET 4, the ASP.NET Empty Web Application template does not include this setting in the default web.config, and neither did the older 3.5 templates. Hence, there are likely a lot of WebForms apps out there that don’t have that setting enabled in their web.config files.

There are a couple different ways this could be resolved, but it seems like the simplest would be to add the runAllManagedModulesForAllRequests setting to the web.config.transform file. But this isn’t something that we wanted to force on people. Our other option was to simply remove the .js extension, after all given that we have total control over the URL the .js was only there for the sake of convention.

When we did this we had the unfortunate side effect of being picked up by some people’s authentication process. Most people have rules in place to exclude .css, .js, etc from being process by mvc, but since we removed the extension this brought Glimpse up on their radar and meant that additional rules needed to be added especially for Glimpse which is not what we wanted.

Problem 3
ASP.NET 4 has the concept of extensionless URL request-handlers, however when RTM shipped, they only worked for files ending with a dot, not for files with no extension. There is a knowledge base article and Hotfix: 980368. Needless to say we weren’t aware of this issue when we made the decision to go with extensionless URL’s.

After applying this patch, extensionless URL request-handlers do actually work for requests without extensions. Service Pack 1 for Win7 and 2008 R2 includes this hotfix, and it turns out all the environments we are testing had this hotfix.

There is a good post about this here – How ASP.NET MVC Routing Works and its Impact on the Performance of Static Requests.

Resolution and Final Fix
I am hoping that anyone reading this can sympathize with trying to work through these various issues at once. I’m a fan of Dr. House and there is never more than one thing wrong with someone at once, but as it turns out this is does not hold true with software. Trying to make sure that people who were still reporting 404 issues had the right versions of the code, when some people did and some didn’t… Needless to say it took a little bit, but I think we now have a total and permanent solution!

The finial resolution we have settled on is to dump /Glimpse/Config all together and go with the more traditional /Glimpse.axd. To me this is really disappointing as the /Glimpse/Config address seems far more elegant. But when developing a tool like Glimpse and having a situation where people need to install hotfixes or unusual changes to your config or anything else like this isn’t a good thing. The bar to entry should be as low as possible and in this case it means going with a /Glimpse.axd URL.

This has the advantage that most people already have rules and procedures in place to deal with *.axd’s and its something that people understand. There are also other well established tools such as ELMAH which use this practice, work in almost every case and people are already using. It does mean we will be adding a few more things to your config moving forward, but we since we are doing the exact same thing as ELMAH (from a config transformation perspective) we feel there is already a well established precedence for this.

In the next release of Glimpse /Glimpse/Config will still exist but will inform people of the change and the fact that they should use /Glimpse.axd moving forward.

In addition, we’ve moved away from leveraging DynamicModuleUtility since many users did not have Microsoft.Web.Infrastructure installed on their server.  For users who download Glimpse via NuGet, this has very little impact because we can leverage web.config transforms to register the HttpModule instead.

Please let us know your thoughts and if you have any feedback or thoughts.


IGlimpsePlugin – Replacing HttpApplication with HttpContextBase

In an effort to try and give the community as much time to respond as possible, if you have noticed already IGlimpsePlugin has had some changes made to it. These changes will go out with release 0.83+.

It is not our intention to make this a pain for people who have already created plugins, but we really felt that this was a change that needed to happen sooner rather than later.

In an effort to ensure that Glimpse is rock solid and “future proof” we have been working hard at getting our test coverage up. In the process of doing this we found that having plugins (IGlimpsePlugin) depend on HttpApplication was a mistake. HttpApplication limits the ability to unit test plugins as it virtual requires us to have a real context.

Obviously this isn’t good for testing and what we should have depended on in the first place is HttpContextBase. HttpContextBase can easily be mocked and hence allows our plugins testable. In the long run this is also good for 3rd party plugin developers as it means that you can easily test as well.

A release will be coming within the next week and we would encourage any developers who have created plugins to adjust their code to cater for the coming change.

Moving forward we don’t anticipate any more changes that any more changes will occur, but this is always a possibility as we are still officially in Beta.

If you have any feedback or comments please let us know. We really do want to make Glimpse the best possible tool and really help facilitate people solving real problems.

Glimpse blog goes live

Well it finally happened; Glimpse now officially has a blog! It is our hope that this will provide a more effective means by which we can communicate with you and another way that you can provide less formal feedback to us.

It’s been an amazing ride since we first “launched” at Mix11. It might be a fair question to ask why we haven’t had a blog earlier, or why we haven’t had more help documentation, etc. As of 2 months ago at Mix, we only had the Github repository and 0 downloads. With the level of enthusiasm (a much support from the likes of Scott Hanselman @shanselman and Phil Haack @haacked) and excitement we received that night, within the next 48hrs, we launched the website (which was created during the keynote), had released another 2 releases delivering primarily feature requests, we had over 300 downloads and to our greatest surprise it seemed to work pretty well out of the box for anyone who tried it.

Today, we not only launch the blog but we are well on our way to reaching 10,000 downloads. Glimpse is one of the most popular ASP.NET Nuget package, thanks to you our users. We have received incredible support from the community (certainly more than we ever expected) and we continue to get more community interest to contribute almost literally every day.

Moving forward things are only going to get better. We are going to continue to need your feedback and guidance as to where we should go, what we should do, where we are going right and where we are going wrong…

With this in mind one of our current top priorities has been working on Help documentation. We continue to get requests from people wanting to know more about how to use and extend Glimpse in more complex ways. Instead of making responses available on just a 1-on-1 basis we would like to make the information/knowledge available to everyone. In addition, we are working on solidify support for WebForms and MVC3, and at the same time making the experience for plugin developers even better. Beyond this, we have some really exciting stuff coming. We have no shortage of ideas and we really want to make Glimpse a must have for web development.

Finally, what can you expect from this blog; first and foremost supported by twitter we intend to make anocements and publish news, we also intend to float ideas about upcoming features and take feedback on what people thing, informal help articles to both users and plugin devs will be published before they are formalized and integrated into the help, and generally anything else that makes sense to include.

Thanks again and please subscribe to the feed!