Krzysztof, Nope, no generics. I know it has something to do with my IUserInfo registration because if I remove the parameterless ctor and replace it with one that requires only an IUserInfo, Windsor tells me it can't find any matching constructors.
I pulled down the Windsor 2.5.x code yesterday and plugged it into my project for debugging. During constructor scoring (when it's trying to find the best ctor), it finds the ctor I want it to find, but once it checks to see if it can resolve the IUserInfo, it's handler is not in a valid state (WaitingDependency) so that ctor is thrown out and it falls back to the parameterless ctor. Yet I can manually call .Resvole() on the IUserInfo and it is resolved. I may try single stepping through the sample project I posted on StackOverflow (http://stackoverflow.com/questions/9315836/missing-dependency-when-using-dynamicparameters) to see if the resolution process happens differently. There must be some reason the dynamicparameters are resolved in my test but not in my real code. Thanks for the response! --- Patrick Steele http://weblogs.asp.net/psteele On Fri, Feb 17, 2012 at 7:15 PM, Krzysztof Koźmic <[email protected]> wrote: > 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. > -- 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.
