What’s new in Windsor 3: Container debugger diagnostics improvements

As we’re nearing the release date of Castle Windsor 3.0 (codename Wawel) I will be blogging about some of the new features and improvements introduced in the new version.

In the previous post I introduced one new diagnostic, and in this post we’ll explore other improvements in this area.


In the screenshot below (and all other) the upper window is Windsor 2.5, lower window is Windsor 3. All screenshots were taken running one of open source applications.


As you can see there are some additional diagnostics present in the new version. Altogether the number rose from 4 in previous version to 7 in Wawel (you’re not seeing all of them in the screenshots above because some of them only activate if they have something to show). The new ones are:

  • Default component per service – if you have multiple components exposing one service this will show you which one of them is the default (that is which one will be used primarily to satisfy dependencies of that type).
  • Potential Service Locator usage was discussed previously

Objects tracked by release policy


This one is pretty self explanatory. It shows you all objects tracked by release policy in your container, grouped by component. Do not underestimate the value of it. This is a fantastic tool for locating objects with mismanaged lifetime (in other words – objects that should have been released but weren’t). If you see a number next to any of your components is suspiciously high or rising you may have just discovered a flaw in lifetime management in your app.

It is worth noting that there were some significant changes around release policies in Windsor 3 and what is tracked by the policy has changed as well. Those changes will be covered in a future post.

Components view

Most of the debugger views deals with showing components and there are some improvements in this area. Let’s go through most notable of them.


  • Top level view no longer shows a sequence number as “Name”. The number had no real meaning and we’re showing instead a much more important information – lifestyle of the component.
  • If lifestyle was not set explicitly (and Windsor falls back to its default for it) there will be an additional star (*) next to the lifestyle, like the “Now” component on the screenshot.
  • How we display the component was also greatly simplified to make it much more readable.
    • We’re not showing the name Windsor’s using for the component, unless you explicitly set it. Otherwise it’s just noise.
    • We’re showing C#-ified names of types so that they are much easier to read.
    • To show open generic services we put dots (·) around generic parameters, so that they stand out from normal types.

Several other more minor improvements were introduced as well, but I won’t go into too much detail here.

Accessing diagnostics in code

Ever since the feature was introduced there were requests to provide programmable access to those diagnostics. It is now possible. Thanks to changes in internal infrastructure you can use new IDiagnostic<> interface (and it’s subinterfaces) to write code like this:

var host = Container.Kernel.GetSubSystem(SubSystemConstants.DiagnosticsKey) as IDiagnosticsHost;
var diagnostic = host.GetDiagnostic<IUsingContainerAsServiceLocatorDiagnostic>();
var serviceLocators = diagnostic.Inspect();

I hope you’ll find all of those improvements useful.

  • Krzysztof, what’s the target release date for 3.0?

    • Krzysztof


      No date yet. Roughly, we’re aiming at late 2nd/early 3rd quarter of the year. Pre-release builds will start appearing sooner, hopefully within a month.

  • @openid-80368:disqus
    no hard date yet, but sometime within next few months