castle-windsor

I would like to write a test that just ensures that all components registered to my WindsorContainer can indeed be resolved. Anyone have any ideas how I can do that? See these posts from Bil Simser: http://weblogs.asp.net/bsimser/archive/2008/06/04/the-first-spec-you-should-write-when-using-castle.aspx http://weblogs.asp.net/bsimser/archive/2008/06/27/testing-castle-windsor-mappings-part-deux.aspx 来源： https://stackoverflow.com/questions/731616/castle-windsor-how-to-test-that-all-registered-components-are-resolvable

I am attempting to build a system that allows users to perform certain actions, but their account must have a specific 'Ticket' per time they do it. For instance, suppose they wish to create a Product , they would need a CreateProductTicket . I could simply do this with some 'if' statements, sure, but I want to try a bit more of a robust solution. My structure looks something like this... interface ITicket<T> where T : ITicketable { } My basic goal is to build an Attribute, perhaps like the following.. public class TicketRequiredAttribute : Attribute { public TicketRequiredAttribute(ITicket<T>

I have the following: public interface ISubject { ... } public class Subject<T> : ISubject { ... } public class MyCode<T> { ... pulic void MyMethod() { var item = container.Resolve<ISubject>(); //????? how do I pass in T } ... } In this case how do i do the resolve. Cheers Anthony vdhant - That's not how containers are meant to be used. You want to use ISubject , right?. Then if you passed T you're breaking your abstraction, because your caller must know that ISubject , is actually a Subject, and more than that, its a Subject<T> and that it requires a concrete T. No container will allow that,

I have a property on my classes for logging service. private ILogger logger = NullLogger.Instance; public ILogger Logger { get { return logger; } set { logger = value; } } And I have this in my component registration: container.AddFacility<LoggingFacility>(x => new LoggingFacility(LoggerImplementation.Log4net)); However, Windsor doesn't seem to inject the Logger - am I missing something? The lambda parameter for AddFacility is actually a creation callback (it gets called when the facility is created), not a factory. Use this instead: container.AddFacility("logging", new LoggingFacility

I am trying to wire up my Web Api project to use Castle Windsor for IoC I have done that for my controllers by following this excellent article . I am now trying to get dependencies injected into my DelegatingHandler and ActionFilterAttribute I have tried to copy the techniques used for filters in regular ASP.Net MVC but they don't seem to apply in Web Api has anyone managed to get this working? I'm not sure what the relevant extension point is in the Web Api I have seen this being suggested config.MessageHandlers.Add(_myContainer.Resolve<IApiUsageLogger>()); but not sure if there is a better

After all what I have read about Dependency Injection and IoC I have decided to try to use Windsor Container within our application (it's a 50K LOC multi-layer web app, so I hope it's not an overkill there). I have used a simple static class for wrapping the container and I initialize it when starting the app, which works quite fine for now. My question is about unit testing. I know that DI is going to make my life much easier there by giving me the possibility of injecting stub / mock implementations of class collaborators to the class under test. I have already written a couple of tests