Windsor currently does not support that, and it’s by design. The reasoning is that you should explicitly register types you need so that you dont get misconfigured object. There is however a possibility that there will be added a hook to create non-registered type at some point in the near future, as this is needed … Read more
This is an old question but Google led me here recently so thought I would share my solution lest it help someone looking for something like StructureMap’s BuildUp method for Windsor. I found that I could add this functionality myself relatively easily. Here is an example which just injects dependencies into an object where it … Read more
I just blogged about this with a solution. In a nutshell, this solution involves a simple, reusable MembershipProvider that calls the container to resolve your custom MembershipProviders. Unlike other solutions that use “BuildUp” container features, this one takes true control of instantiation, thus enabling constructor injection (which in turn enables immutability) and proxyability.
AFAIK no dependency injection container can directly manage an attribute, since it’s instantiated by the runtime and there’s no way to intercept that. However, they can cheat by either: Using a static gateway to the container (example), or Using a “BuildUp” feature that injects whatever dependencies are found within an already-constructed object. This is called … Read more
The simplest way to get this to work is to use ASP.NET’s standard mechanism of <membership> in web.config. You just let it use the default constructor but you override Initialize() and pull the dependencies there. Use this as reference. Personally, due to things like this, I prefer to avoid the provider model altogether so I … Read more
Just for the sake of completeness, an answer I got from Krzysztof Koźmic (the current maintainer of Castle Windsor) on Twitter indicated that the method outlined in the question is, indeed, the correct way of achieving this particular goal. (However, I can’t link to that tweet, since Krzysztof’s twitter account is protected (tweets are not … Read more
I think you’re basically on the right track – If you have not already I would suggest taking a look at Rhino Igloo, an WebForms MVC framework, Here’s a good blog post on this and the source is here – Ayende (the Author of Rhino Igloo) tackles the issue of using Windsor with webforms quite … Read more
currently this is not supported OOTB due to the fact that Windsor always favours mode specific component over an open-generic. You can get that working quite easily with an ISubDependencyResolver though. The code below assumes you name the component for your decorator “DeadlockRetryCommandHandlerDecorator” public class CommandHandlerResolver : ISubDependencyResolver { private readonly IKernel kernel; public FooResolver(IKernel … Read more
The MVC3 IDependencyResolver interface has a big problem: no release method. This means that there is a potential memory leak if you are going to use it with Windsor. See my blog post about it here: http://mikehadlow.blogspot.com/2011/02/mvc-30-idependencyresolver-interface-is.html
Having recently spiked the use of 6 of these (Windsor, Unity, Spring.Net, Autofac, Ninject, StructureMap) I can offer a quick summary of each, our selection criteria and our final choice. Note: we did not look at PicoContainer.Net as one of our team considered the .Net port to be quite poor from the Java version. We … Read more