New Castle Windsor feature – debugger diagnostics

What you’re seeing here, is a feature in very early stages of development. It’s very likely to change in the very near future, hopefully based on your feedback which I’m looking forward to.

It is often the case with IoC containers, especially when registering components by convention, that you end up with misconfigured components, or with an exception saying that your component can’t be resolved. To aid working in these situations StructureMap provides methods like WhatDoIHave and AssertConfigurationIsValid. That’s the only container I know of that provides this kind of diagnostics.

Windsor also has similar ability to StructureMap’s WhatDoIHave method. It’s very powerful as well, since Windsor tracks internally the entire graph of objects and lets you access it you can for example visualize it.

The AssertConfigurationIsValid is a tougher nut to crack. Thing is – you can’t really say when the configuration is valid in any non trivial situation. You can’t say when it’s non-valid either. The reason for that is that there are multiple dynamic moving parts that you can’t really statically analyse to output a yes/no value.

What Windsor does

To help with these situations when debugging, in Windsor 2.5 I added debugging proxies to the most important classes in Windsor, so that when looking at them in the debugger you will be presented with much more helpful view of what’s in the container and what’s potentially not right.

debugger_visualizer

You will see a very minimalistic view of what’s going on in the container:

  • All components – will give you a list of all existing components in the container, kind of like WhatDoIHave
  • Facilities will give you the list of the installed facilities
  • Potentially misconfigured components – this is a list of components that don’t look to good to Windsor and may have some dependencies missing. It also is a very simplified view. At the first glance it will only tell you the key of the component (in this case fully qualified name), slash service/implementation. In this case both service and implementation are the same, so it won’t repeat the information.
    When you drill down, you will also see the lifestyle of the component and most importantly its status, which will tell you why Windsor thinks there may be something wrong with the component.

debugger_visualizer2

This pretty nicely tells you what might be wrong. If you are sure you providing these values dynamically, be it from the call site or via dynamic parameters, you can move on, otherwise it can remind you of the missing dependencies.

I want your feedback

How do you like this feature? How would you change it? What other information you think would be useful in this view? Leave a comment, or go to uservoice site to share your ideas.

Thanks

5 Thoughts.

  1. Really interesting article. For me it would be very valuable to be able to write a test that takes my IWindsorInstaller, register it in a test container, And try to simulate a resolution of every component (like a foreach on WhatDoIHave).
    I think at the process of simulating resolution like a "dry run" of IKernel.Resolve

  2. Yes, but the test in the post actually resolve all dependencies, because there’s no way to do a "dry run". Also, during resolution would be nice to have some sort of warning when potentially dangerous dependency graph are found (singletons that depends on transients for example)

  3. @Gian Marco Gherardi

    What do you mean by dry run? The issue is that there are too many moving parts to be 100% sure you will resolve the component properly. It can depend on the other components, it can depend on external context, like web request. It can resolve once correctly, another time it won’t. It may depend on arguments being passed from the call site etc.

    That’s why the debugger proxy calls it *potentially* misconfigured component.

    Doing logging is something I intend to add for Windsor 3.

  4. Although these new debugging features are useful, I try to stay away from the debugger as much as possible – it’s time consuming and it requires manual work. What I try to do in my projects which use Castle is to write unit tests to check certain conventions I try to enforce. This way errors can be detected as soon as something changes in the code.

    You expressed concerns about trying to detect container problems in a dynamic environment. One idea: what if the Castle resolver had an extension point where one could hook up his own checks? This way the check would be performed right at the point of resolving components. It’s not ideal, since the failure point would not necessarily occur during the application initialization (it could break down later when a factory is called, for example) but at least you would get a better indication of problems in your code.

    One example: do you see a valid scenario of a singleton component that depends on a per-request component (or the dependency is resolved using a per-request component)? I don’t, and this would probably be a good check to perform for Web apps.

Comments are closed.