New Castle Windsor feature – debugger diagnostics

Posted by under Castle, Design, Windsor July 2nd, 2010

What you’re see­ing here, is a fea­ture in very early stages of devel­op­ment. It’s very likely to change in the very near future, hope­fully based on your feed­back which I’m look­ing for­ward to.

It is often the case with IoC con­tain­ers, espe­cially when reg­is­ter­ing com­po­nents by con­ven­tion, that you end up with mis­con­fig­ured com­po­nents, or with an excep­tion say­ing that your com­po­nent can’t be resolved. To aid work­ing in these sit­u­a­tions Struc­tureMap pro­vides meth­ods like What­DoI­Have and Assert­Con­fig­u­ra­tionIs­Valid. That’s the only con­tainer I know of that pro­vides this kind of diagnostics.

Wind­sor also has sim­i­lar abil­ity to StructureMap’s What­DoI­Have method. It’s very pow­er­ful as well, since Wind­sor tracks inter­nally the entire graph of objects and lets you access it you can for exam­ple visu­al­ize it.

The Assert­Con­fig­u­ra­tionIs­Valid is a tougher nut to crack. Thing is – you can’t really say when the con­fig­u­ra­tion is valid in any non triv­ial sit­u­a­tion. You can’t say when it’s non-valid either. The rea­son for that is that there are mul­ti­ple dynamic mov­ing parts that you can’t really sta­t­i­cally analyse to out­put a yes/no value.

What Wind­sor does

To help with these sit­u­a­tions when debug­ging, in Wind­sor 2.5 I added debug­ging prox­ies to the most impor­tant classes in Wind­sor, so that when look­ing at them in the debug­ger you will be pre­sented with much more help­ful view of what’s in the con­tainer and what’s poten­tially not right.

debugger_visualizer

You will see a very min­i­mal­is­tic view of what’s going on in the container:

  • All com­po­nents – will give you a list of all exist­ing com­po­nents in the con­tainer, kind of like WhatDoIHave
  • Facil­i­ties will give you the list of the installed facilities
  • Poten­tially mis­con­fig­ured com­po­nents – this is a list of com­po­nents that don’t look to good to Wind­sor and may have some depen­den­cies miss­ing. It also is a very sim­pli­fied view. At the first glance it will only tell you the key of the com­po­nent (in this case fully qual­i­fied name), slash service/implementation. In this case both ser­vice and imple­men­ta­tion are the same, so it won’t repeat the infor­ma­tion.
    When you drill down, you will also see the lifestyle of the com­po­nent and most impor­tantly its sta­tus, which will tell you why Wind­sor thinks there may be some­thing wrong with the component.

debugger_visualizer2

This pretty nicely tells you what might be wrong. If you are sure you pro­vid­ing these val­ues dynam­i­cally, be it from the call site or via dynamic para­me­ters, you can move on, oth­er­wise it can remind you of the miss­ing dependencies.

I want your feedback

How do you like this fea­ture? How would you change it? What other infor­ma­tion you think would be use­ful in this view? Leave a com­ment, or go to user­voice site to share your ideas.

Thanks

  • http://twitter.com/gianmarcog Gian Marco Gherardi

    Really inter­est­ing arti­cle. For me it would be very valu­able to be able to write a test that takes my IWind­sorIn­staller, reg­is­ter it in a test con­tainer, And try to sim­u­late a res­o­lu­tion of every com­po­nent (like a fore­ach on What­DoI­Have).
    I think at the process of sim­u­lat­ing res­o­lu­tion like a "dry run" of IKernel.Resolve

  • http://kozmic.pl/Default.aspx Krzysztof Koźmic

    @Gian Marco Gher­ardi
    you meant this:
    weblogs.asp.net/…/…sor-mappings-part-deux.aspx

  • http://twitter.com/gianmarcog Gian Marco Gherardi

    Yes, but the test in the post actu­ally resolve all depen­den­cies, because there's no way to do a "dry run". Also, dur­ing res­o­lu­tion would be nice to have some sort of warn­ing when poten­tially dan­ger­ous depen­dency graph are found (sin­gle­tons that depends on tran­sients for example)

  • http://kozmic.pl/Default.aspx Krzysztof Koźmic

    @Gian Marco Gherardi

    What do you mean by dry run? The issue is that there are too many mov­ing parts to be 100% sure you will resolve the com­po­nent prop­erly. It can depend on the other com­po­nents, it can depend on exter­nal con­text, like web request. It can resolve once cor­rectly, another time it won't. It may depend on argu­ments being passed from the call site etc.

    That's why the debug­ger proxy calls it *poten­tially* mis­con­fig­ured component.

    Doing log­ging is some­thing I intend to add for Wind­sor 3.

  • http://igorbrejc.net/ Igor Brejc

    Although these new debug­ging fea­tures are use­ful, I try to stay away from the debug­ger as much as pos­si­ble — it's time con­sum­ing and it requires man­ual work. What I try to do in my projects which use Cas­tle is to write unit tests to check cer­tain con­ven­tions I try to enforce. This way errors can be detected as soon as some­thing changes in the code.

    You expressed con­cerns about try­ing to detect con­tainer prob­lems in a dynamic envi­ron­ment. One idea: what if the Cas­tle resolver had an exten­sion point where one could hook up his own checks? This way the check would be per­formed right at the point of resolv­ing com­po­nents. It's not ideal, since the fail­ure point would not nec­es­sar­ily occur dur­ing the appli­ca­tion ini­tial­iza­tion (it could break down later when a fac­tory is called, for exam­ple) but at least you would get a bet­ter indi­ca­tion of prob­lems in your code.

    One exam­ple: do you see a valid sce­nario of a sin­gle­ton com­po­nent that depends on a per-request com­po­nent (or the depen­dency is resolved using a per-request com­po­nent)? I don't, and this would prob­a­bly be a good check to per­form for Web apps.