Again: please create a running test-case (code is always easier to debug than english :-) )
Also, if you want to inject arrays of services you need to add the ArrayResolver: http://stackoverflow.com/questions/1057977/castle-windsor-cant-inject-an-array-of-interface-types On Sep 16, 1:24 am, Shawn Moroney <[email protected]> wrote: > This has been driving me kinda nuts the past few days. > > Take iniatiative and implment some new stuff at work, and I guess that > happens sometimes. :D > > This is a WPF application. > > The jist of it -- I want a view model (Object A) to be resolved when a form > is opened (which I thought could be done by putting a reference to the > container [located in App.Xaml, available to the application] and resolving > Object A in the code behind of the page...but as a member of Object A is a > collection of objects (Object B's) that is loaded (each object instantiated > and put into the collection) from inside of code in Object A, during > initialization. Now, inside of an Object B is an interface/dependency (the > interface we'll call Object C, even though it's just an interface, but will > be injected with the object.) Object C has another interface/dependency. > And finally, Object C has an interface/dependency as a member -- Object D. > > Everything was put in the container. Pretty sure. I can double check, of > course. > > Here are the questions --- > -- Is there a way, from the code behind of the form, to initialize ALL > dependenies, without putting a reference/dependency in each of the child > objects? > > I say this because if I say in, for example, Object A, to have a reference to > the container (located as a member of App.xaml) to do the resolution to the > topmost interface/dependency, then I create a dependency on the App.xaml > property, right? I can't unit test Object A because of the dependency to > App.xaml in a WPF application, right? > > Is there just a way to call resolution on object A, and in A, when each B is > instantated, have it AUTOMATICALLY have it's dependencies (and their child > dependencies) resolved without an explicit call in A to do so? > > -- Because there is a collection in Object A (of Object B's) > > -- Also, I tried putting an Object C as a child of Object A, just for > curiosity's sake, and doing the resolution in the form's code behind (as > normal). While C was resolved, D (the child of C) was not. So is there an > issue with resolving child dependencies (rather than a dependency as a DIRECT > child of an object being resolved)? > > _________________________________________________________________ > Hotmail: Powerful Free email with security by > Microsoft.http://clk.atdmt.com/GBL/go/171222986/direct/01/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
