They are just a bit more dynamic than an anonymous object or a dictionary passed into DynamicParameters. Wouldn't it work to run that delegate at resolve time to update CurrentState? Of course, with some sort of indicator to explicitly advise the container to do this, else it would probably slow down things a lot.
Since I'm using this<http://mikehadlow.blogspot.co.at/2010/02/10-advanced-windsor-tricks-9.html>trick here, I could've imagined implementing something similar to Parameter and ServiceOverrides that lets me specify an explicit dependency on another component (with possibly implicit/case-insensitive mapping of properties to ctor-parameters) - however, I didn't get around to try this yet, so I'll be stuck with the UsingFactoryMethod workaround for now. On Monday, February 18, 2013 10:26:55 PM UTC+1, Krzysztof Koźmic wrote: > > Yeah, since dynamic parameters are just that - dynamic, WIndsor has no > way to statically determine which parameters will be provided. > > The workaround for now is to make the property mandatory when registering > Foo > > HTH > -- > Krzysztof Kozmic > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/castle-project-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
