Patrick,

In real code, are there any generics involved? There's a known issue in Windsor's resolution where it doesn't pick up an open generic dependency properly in certain cases:
issues.castleproject.org/issue/IOC-322

Could that be it?
@K



On 17/02/2012 11:06 PM, Patrick Steele wrote:
I'm looking for ideas from Windsor users as to what might be causing a
problem I'm seeing.  I've tried for hours to create a test case that
would reproduce this problem and I can't.  There must be something I'm
not seeing so I thought a few extra pairs of eyes would help.

I'm converting an old WinForms app to use Windsor (2.5.4.32) instead
of a hand-rolled IOC container.  The old container did not support a
lot of the advanced features of Windsor.  At one point during
initialization, I had to create a component myself, which needed to
get information from another component in the container, and then
stick the component into the container.  I ported that code to Windsor
as this:

var ts = container.Resolve<ISettings>();
IUserInfo userInfo = new LDAPUserInfo(ts.AdditionalDCs);
container.Register(Component.For<IUserInfo>().Instance(userInfo));

The IUserInfo dependency was used inside the app's main form (IA, IB
and IC are all registered inside Windsor too and resolve properly):

public MainForm()
{
        InitializeComponent();
}

public MainForm(IA a, IB b, IC c, IUserInfo userInfo)
        : this()
{
        ...
}

And everything worked fine.

Now that I'm using Windsor, I decided I'd get rid of the old
registration code for IUserInfo and do it using Windsor's
DynamicProperties (this also gives me the bonus that any other
dependencies inside LDAPUserInfo I may add in the future can now be
resolved by Windsor).  So I changed the code to this:

container.Register(Component.For<IUserInfo>().ImplementedBy<LDAPUserInfo>().
        DynamicParameters((k, p) =>
        {
                var ts = k.Resolve<ISettings>();
                p["additionalDomainControllers"] = ts.AdditionalDCs;
        }));

Now Windsor stops using my ctor that takes an IUserInfo and falls back
to using only the parameterless ctor.  I've wrestled with this for so
long (and tried without luck to create this in a unit test) I'm
totally out of ideas.  I know it's the IUserInfo thats causing the
ctor resolution problem because if I change the MainForm resolution
code from:

Application.Run(container.Resolve<MainForm>());

to:

Application.Run(container.Resolve<MainForm>(new { userInfo =
container.Resolve<IUserInfo>() }));

Then Windsor picks the correct ctor -- and the IUserInfo passed to the
ctor is initialized properly.  Does anyone see anything that looks
wrong?  Unfortunately, I can't show the entire code due to NDA stuff.
At this point, I'm looking for ideas.

Thanks!

---
Patrick Steele
http://weblogs.asp.net/psteele


--
You received this message because you are subscribed to the Google Groups "Castle 
Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en.

Reply via email to