Castle Windsor does not resolve AutoMapper profiles after update - castle-windsor

Everything was working fine until I updated with NuGet the references for CastleWinsor and AutoMapper to their latest versions: Castle.Windsor.3.0.0.4001 and AutoMapper.2.0.0.
I have a list of AutoMapper profiles in the same assembly as the AutoMapperInstaller : IWindsorInstaller. They are in diferent namespaces, but this should not matter, right?
Here is a profile example:
namespace FieldService.Web.Mappings
{
public class RoleMappings : Profile
{
protected override void Configure()
{
AutoMapper.Mapper.CreateMap<RoleModel, Role>()
.ConstructUsing((role) => new Role() { Permissions = new List<Permission>() })
.ForMember(m => m.Permissions, o => o.MapFrom(src => src.Permissions.Where(p => p.Selected == true)));
}
}
}
Here is the AutoMapperInstaller
namespace FieldService.Web.Infrastructure.IOC
{
public class AutoMapperInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
Mapper.Initialize(x => x.ConstructServicesUsing(container.Resolve));
RegisterProfilesAndResolvers(container);
RegisterMapperEngine(container);
}
private void RegisterMapperEngine(IWindsorContainer container)
{
container.Register(
Component.For<IMappingEngine>().Instance(Mapper.Engine)
);
}
private void RegisterProfilesAndResolvers(IWindsorContainer container)
{
// register value resolvers
container.Register(AllTypes.FromAssembly(Assembly.GetExecutingAssembly()).BasedOn<IValueResolver>());
// register profiles
container.Register(AllTypes.FromThisAssembly().BasedOn<Profile>());
var profiles = container.ResolveAll<Profile>();
foreach (var profile in profiles)
Mapper.AddProfile(profile);
}
}
}
In Global.asax I have the method BootstrapContainer which I call from Application_Start method:
private static readonly IWindsorContainer container = new WindsorContainer();
public IWindsorContainer Container
{
get { return container; }
}
private static void BootstrapContainer()
{
container.Install(FromAssembly.This());
}
The exception I get is: Trying to map xxx to yyyModel. Missing type map configuration or unsupported mapping. Exception of type 'AutoMapper.AutoMapperMappingException' was thrown.
I debugged the installer and I think this line Container.Register(AllTypes.FromThisAssembly().BasedOn<Profile>()); is not working anymore.
If I try to resolve the profiles (next line) it returns 0 profiles.
I am not an expert with these two tools, and I am not sure this is the best method to initialize AutoMapper with Windsor but it worked until now.
Any idea why this is not working anymore?

This is a known and documented breaking change in Windsor (see breakingchanges.txt for details).
In short, if you're resolving your profiles as Profile you need to register them as Profile.
Container.Register(AllTypes.FromThisAssembly().BasedOn<Profile>().WithServiceBase());

For me this code worked :
public class AutoMapperInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
// Register all mapper profiles
container.Register(
Classes.FromAssemblyInThisApplication(GetType().Assembly)
.BasedOn<Profile>().WithServiceBase());
// Register IConfigurationProvider with all registered profiles
container.Register(Component.For<IConfigurationProvider>().UsingFactoryMethod(kernel =>
{
return new MapperConfiguration(configuration =>
{
kernel.ResolveAll<Profile>().ToList().ForEach(configuration.AddProfile);
});
}).LifestyleSingleton());
// Register IMapper with registered IConfigurationProvider
container.Register(
Component.For<IMapper>().UsingFactoryMethod(kernel =>
new Mapper(kernel.Resolve<IConfigurationProvider>(), kernel.Resolve)));
}
}

Related

How to load to container MassTransit EndPoint in AbstractFacility

I have a PersistenceFacility class .
This class inhereted "AbstractFacility" as "Castle.MicroKernel.Facilities".
I wonder load and install into container: IWindsorContainer.
public class PersistenceFacility: AbstractFacility
{
protected override void Init()
{
ServiceIoC.Container.Register(Component.For<IBusControl>().LifeStyle.Singleton.UsingFactoryMethod(k =>
{
var busControl = Bus.Factory.CreateUsingRabbitMq(config =>
{
config.Host(new Uri("blabla"), host =>
{
host.Username("guest");
host.Password("guest");
});
config.ReceiveEndpoint("", endpoint =>
{
endpoint.EnableMessageScope();
// Above method works but it is deprecated, instead below method should be used to get Consumer from container.
//endPoint.Consumer<YourConsumer>(container.Kernel);
});
});
return busControl;
}).LifeStyle.Singleton.Named("XXXMassTransitRMQ"));
}
// installer class
public class PersistenceInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container?.AddFacility<PersistenceFacility>();
}
}
//UOW Class
public class UnitOfWork
{
internal static IBusControl MassTransitRmqControl => ServiceIoC.Container?.Resolve<IBusControl>("XXXMassTransitRMQ");
}
First, I would consider moving to use the new container support for Windsor, as outlined in the documentation.
You can see how MassTransit registers components with Windsor by looking at the configuration.
I'm not sure an abstract facility is the way to go, given the approach taken by the links referenced above.

Castle Windsor: get informed by the container after any object was resolved

I'm using Castle Windsor as DI Container and have following question:
Is it possible to get informed by the container each time, any object was created by the container and get a reference to this object?
I want to check after each resolve, if the resolved object implements a special interface (e.g. IEmergencyStop). I want to register this object at a special service (EmergencyStopHelper).
Following an example:
interface IEmergencyStop
{
void Stop();
}
interface IMotor : IEmergencyStop
{
void Run();
}
class Motor : IMotor
{
}
class EmergencyStopHelper
{
List<IEmergencyStop> emergencyStopList = new List<IEmergencyStop>();
public void Register(IEmergencyStop aClass)
{
emergencyStopList.Add(aClass);
}
public void StopAll() => emergencyStopList.ForEach( x => x.Stop());
}
container.Register(Component.For<IMotor>().ImplementedBy<Motor>().LifestlyleTransient());
container.Register(Component.For<EmergencyStopHelper>());
// TODO: any magic code which calls EmergencyStopHelper.Register(...)
// after following resolve
IMotor aMotor = container.Resolve<IMotor>();
var emergencyStop = container.Resolve<EmergencyStopHelper>();
emergencyStop.StopAll();

Have Castle Windsor select component based on requestor type namespace

I have an interface ISession whose instance is produced by a different Session Factory depending on which namespace the class belongs to.
Example of my component registration:
IWindsorContainer container = new WindsorContainer();
container.Register(Component.For<NHibernate.ISession>()
.UsingFactoryMethod((kernel, creationContext) =>
{
NHibernate.ISession session =
new SessionFactoryForNamespace1()
.Instance.GetSession();
return session;
})
.LifestylePerWebRequest());
container.Register(Component.For<NHibernate.ISession>()
.UsingFactoryMethod((kernel, creationContext) =>
{
NHibernate.ISession session =
new SessionFactoryForNamespace2()
.Instance.GetSession();
return session;
})
.LifestylePerWebRequest());
container.Register(Component.For<Namespace1.IRepository1()
.ImplementedBy<Namespace1.Repository1>());
container.Register(Component.For<Namespace2.IRepository2>()
.ImplementedBy<Namespace2.Repository2>());
Example of the resolution graph:
public class MyController
{
public MyController(Namespace1.IRepository1 repo1,
Namespace2.IRepository2 repo2) { }
}
namespace Namespace1
{
public interface IRepository1 { }
public class Repository1 : IRepository1
{
public Repository1(NHibernate.ISession session) { }
}
}
namespace Namespace2
{
public interface IRepository2 { }
public class Repository2 : IRepository2
{
public Repository2(NHibernate.ISession session) { }
}
}
When Castle Windsor is asked to resolve MyController, it then tries to resolve IRepository1 and IRepository2, and subsequently the ISession for each. I want to have Castle Windsor select the component handlers based on the requestor type's namespace which in my example is either Namespace1 or Namespace2.
I am new to Castle Windsor and not sure where in the resolution pipeline I'm supposed to be plugging into.
What is the best approach to accomplish what I have outlined above?
I think a service override would work for this.
UPDATE:
I also did an article on some of Windsor's advanced features (including a section on Service Overrides) that should augment the documentation linked above.
Here is how I implemented service override solution:
Repository interfaces now inherit from a common repository interface:
public class MyController
{
public MyController(Namespace1.IRepository1 repo1,
Namespace2.IRepository2 repo2) { }
}
public interface IRepository { }
namespace Namespace1
{
public interface IRepository1 : IRepository { }
public class Repository1 : IRepository1
{
public Repository1(NHibernate.ISession session) { }
}
}
namespace Namespace2
{
public interface IRepository2 : IRepository { }
public class Repository2 : IRepository2
{
public Repository2(NHibernate.ISession session) { }
}
}
Repository component registeration based on its namespace:
IWindsorContainer container = new WindsorContainer();
...
Action<Type> RegisterRepository = t =>
{
container.Register(
AllTypes.FromAssemblyContaining(t)
.BasedOn(typeof(IRepository))
.WithServiceAllInterfaces()
.Configure(c =>
{
c.DependsOn(
ServiceOverride
.ForKey<NHibernate.ISession>()
.Eq(c.Implementation.Namespace));
c.LifeStyle.Is(LifestyleType.Transient);
})
);
};
RegisterRepository(typeof(Namespace1.IRepository1));
RegisterRepository(typeof(Namespace2.IRepository2));
Seems to work :)

Castle Windsor: Set component dependencies on existing object

In MEF it's possible to set the dependencies for an existing object using something like:
container.SatisfyImportsOnce(instance);
Is it possible to do the same with Castle Windsor?
I'm using (read: learning) Caliburn.Micro, and trying to update the template project from MEF to Windsor, which is where I've come across the issue.
Sorry Neil, Windsor doesn't have that feature
Castle Windsor FAQ
Windsor will resolve a property dependency (which it considers an optional dependency) such as an ILogger property if there is a registered component for that service. But this only happens during component activation...when the component is constructed the first time, there is no way to pass Windsor an existing instance and inject components into properties.
With Castle Windsor you can register an existing instance with the container, is this the kind of thing you are looking for?
var instance = new Logger();
var container = new WindsorContainer();
container.Register(Component.For<ILogger>().Instance(instance))
where
public interface ILogger
{
void LogException(Exception ex);
}
public class Logger : ILogger
{
public void LogException(Exception ex)
{
// Log exception
}
}
You can however code this functionality yourself. For example, here is an ASP.NET MVC FilterAttributeFilterProvider, used to inject proprties onto attribute action filters.
public class AttributeFilterProvider : FilterAttributeFilterProvider
{
public AttributeFilterProvider(IKernel kernel)
{
_kernel = kernel;
}
private readonly IKernel _kernel;
protected override IEnumerable<FilterAttribute> GetControllerAttributes(ControllerContext controllerContext, ActionDescriptor actionDescriptor)
{
var attributes = base.GetControllerAttributes(controllerContext, actionDescriptor);
BuildUpAttributeDependancies(attributes);
return attributes;
}
protected override IEnumerable<FilterAttribute> GetActionAttributes(ControllerContext controllerContext, ActionDescriptor actionDescriptor)
{
var attributes = base.GetActionAttributes(controllerContext, actionDescriptor);
BuildUpAttributeDependancies(attributes);
return attributes;
}
private void BuildUpAttributeDependancies(IEnumerable<FilterAttribute> attributes)
{
foreach (var attribute in attributes)
{
var propInfos = attribute.GetType().GetProperties().Where(x => x.GetValue(attribute) == null).AsEnumerable();
foreach (var pi in propInfos)
{
if (_kernel.HasComponent(pi.PropertyType))
{
var service = _kernel.Resolve(pi.PropertyType);
pi.SetValue(attribute, service);
}
}
}
}
}
In the BuildUpAttributeDependancies method, we look for un-initialised (null) properties, and then check to see if the type has been registered with Castle Windsor. If it has, we set the property.
By replacing the default FilterAttributeFilterProvider with our custom one (above) in the global.asax file we can now use Castle Windsors DI features to inject any type onto any Action Filter in our MVC application. To complete this answer fully, here is an example of a global.asax application class with Castle Windsor setup for both Controller (at instantiation time) and ActionFilter (at usage time) dependancy injection:
public class MvcApplication : System.Web.HttpApplication
{
private static IWindsorContainer _container;
private static void BootstrapContainer()
{
_container = new WindsorContainer()
.Install(FromAssembly.This());
var controllerFactory = new ControllerFactory(_container.Kernel);
ControllerBuilder.Current.SetControllerFactory(controllerFactory);
}
private static void BootstrapFilters()
{
var oldProvider = FilterProviders.Providers.Single(f => f is FilterAttributeFilterProvider);
FilterProviders.Providers.Remove(oldProvider);
var provider = new AttributeFilterProvider(_container.Kernel);
FilterProviders.Providers.Add(provider);
}
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
BootstrapContainer();
BootstrapFilters();
}
}

Castle Windsor : Possible bug with Startable Facility and "decorator pattern" dependencies

When attempting to register a startable component that depends on a service whose implementation "decorates" the same service interface, Castle fails to resolve the startable component, claiming that the dependency cannot be resolved. Curiously enough, explicitly resolving the startable component works as expected. I have seen this behavior in both Castle Windsor 2.5 and 2.5.1. Please see the below NUnit test case:
UPDATE
I've discovered that I can get the startable mechanism to work, but I need to separate the registrations of the IFoo implementers into a separate container.Register() call from the registration of the startable component. The IFoo registrations must happen first. Even more interestingly, this does not work if I use an IWindsorInstaller to install the components. Please see additional test cases below:
UPDATE
Installing the IFoo implementers in a separate installer, in a separate call to container.Install() works. Installing the startable component by including its IWindsorInstaller in the params[] list to a single call to container.Install() does not work, but installing it in a separate call to container.Install() does work. I have consolidated all test cases into the below code snippet:
using System;
using Castle.Facilities.Startable;
using Castle.MicroKernel.Registration;
using Castle.MicroKernel.SubSystems.Configuration;
using Castle.Windsor;
using NUnit.Framework;
namespace Tests
{
[TestFixture]
public class TestProblemsWithStartableAndDecorators
{
/// <summary>
/// This test passes with the following output to the console:
///
/// foo decorator
/// typeof decorated : Foo
/// startable constructor
/// typeof foo : FooDecorator
///
/// </summary>
[Test]
public void TestUsingResolve()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Register(
Component.For<IFoo>().ImplementedBy<FooDecorator>(),
Component.For<IFoo>().ImplementedBy<Foo>(),
Component.For<IGetStarted>().ImplementedBy<GetStarted>()
);
container.Resolve<IGetStarted>();
}
}
/// <summary>
/// This test should pass with the same output as the above test.
/// However, it fails with the following exeption:
///
/// Castle.MicroKernel.Handlers.HandlerException : Can't create component 'Tests.TestProblemsWithStartableAndDecorators+FooDecorator' as it has dependencies to be satisfied.
/// Tests.TestProblemsWithStartableAndDecorators+FooDecorator is waiting for the following dependencies:
///
/// Services:
/// - Tests.TestProblemsWithStartableAndDecorators+IFoo.
/// A dependency cannot be satisfied by itself, did you forget to add a parameter name to differentiate between the two dependencies?
///
/// Tests.TestProblemsWithStartableAndDecorators+foo is registered and is matching the required service, but cannot be resolved.
/// </summary>
[Test]
public void TestUsingStartable()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Register(
Component.For<IFoo>().ImplementedBy<FooDecorator>(),
Component.For<IFoo>().ImplementedBy<Foo>(),
Component.For<IGetStarted>().ImplementedBy<GetStarted>().Start()
);
}
}
public interface IFoo
{
}
public class Foo : IFoo
{
}
public class FooDecorator : IFoo
{
public FooDecorator(IFoo decorated)
{
Console.WriteLine("foo decorator");
Console.WriteLine(" typeof decorated : " + decorated.GetType().Name);
}
}
public interface IGetStarted
{
}
public class GetStarted : IGetStarted
{
public GetStarted(IFoo foo)
{
Console.WriteLine("startable constructor");
Console.WriteLine(" typeof foo : " + foo.GetType().Name);
}
}
// works
[Test]
public void TestUsingStartableWithSeparateRegistrations()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Register(Component.For<IFoo>().ImplementedBy<FooDecorator>(),
Component.For<IFoo>().ImplementedBy<Foo>());
container.Register(Component.For<IGetStarted>().ImplementedBy<GetStarted>().Start());
}
}
// fails
[Test]
public void TestUsingStartableWithSeparateRegistrationsRegisteringStartableFirst()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Register(Component.For<IGetStarted>().ImplementedBy<GetStarted>().Start());
container.Register(Component.For<IFoo>().ImplementedBy<FooDecorator>(),
Component.For<IFoo>().ImplementedBy<Foo>());
}
}
// fails
[Test]
public void TestUsingStartableWithInstaller()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Install(new TestInstaller());
}
}
public class TestInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container,
IConfigurationStore store)
{
container.Register(Component.For<IFoo>().ImplementedBy<FooDecorator>(),
Component.For<IFoo>().ImplementedBy<Foo>());
container.Register(Component.For<IGetStarted>().ImplementedBy<GetStarted>().Start());
}
}
// works
[Test]
public void TestUsingStartableWithSeparateFooInstaller()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Install(new FooInstaller());
container.Register(Component.For<IGetStarted>().ImplementedBy<GetStarted>().Start());
}
}
// fails
[Test]
public void TestUsingStartableWithSeparateInstallers()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Install(new FooInstaller(), new StartableInstaller());
}
}
// works
[Test]
public void TestUsingStartableWithSeparateCallsToInstall()
{
using (var container = new WindsorContainer())
{
container.AddFacility<StartableFacility>(f => f.DeferredStart());
container.Install(new FooInstaller());
container.Install(new StartableInstaller());
}
}
public class FooInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container,
IConfigurationStore store)
{
container.Register(Component.For<IFoo>().ImplementedBy<FooDecorator>(),
Component.For<IFoo>().ImplementedBy<Foo>());
}
}
public class StartableInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container,
IConfigurationStore store)
{
container.Register(Component.For<IGetStarted>().ImplementedBy<GetStarted>().Start());
}
}
}
}
Fixed in HEAD. Will be part of 2.5.2 release. For future reference, here's the bug report.