Castle bootstrapper for Caliburn.Micro

CastleBootstrapper.cs

// Hooks up Castle Windsor as the container for your Caliburn.Micro application. 
// Turns on support for delegate factory methods (e.g. passing the factory "Func<XyzEditViewModel>" as a constructor arg)
// Dependencies: In addition to Caliburn.Micro you will need to reference Castle.Core and Castle.Windsor

public class CastleBootstrapper<TRootViewModel> : Bootstrapper<TRootViewModel>
{
	private ApplicationContainer _container;

	protected override void Configure()
	{
		_container = new ApplicationContainer();
		_container.AddFacility<TypedFactoryFacility>();
	}

	protected override object GetInstance(Type service, string key)
	{
		return string.IsNullOrWhiteSpace(key)
				   ? _container.Resolve(service)
				   : _container.Resolve(key, service);
	}

	protected override IEnumerable<object> GetAllInstances(Type service)
	{
		return (IEnumerable<object>)_container.ResolveAll(service);
	}

	protected override void BuildUp(object instance)
	{
		instance.GetType().GetProperties()
			.Where(property => property.CanWrite && property.PropertyType.IsPublic)
			.Where(property => _container.Kernel.HasComponent(property.PropertyType))
			.ForEach(property => property.SetValue(instance, _container.Resolve(property.PropertyType), null));
	}
}

public class ApplicationContainer : WindsorContainer
{
    public ApplicationContainer()
    {
        Register(
            Component.For<IWindowManager>().ImplementedBy<WindowManager>().LifeStyle.Is(LifestyleType.Singleton),
            Component.For<IEventAggregator>().ImplementedBy<EventAggregator>().LifeStyle.Is(LifestyleType.Singleton)
            );

        RegisterViewModels();
    }

    private void RegisterViewModels()
    {
        Register(AllTypes.FromAssembly(GetType().Assembly)
                        .Where(x => x.Name.EndsWith("ViewModel"))
                        .Configure(x => x.LifeStyle.Is(LifestyleType.Transient)));
    }
}

// If you don't already have a ForEach extension method in your project here you go:

public static class ForEachExtension
{
	public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
	{
		foreach (T element in source)
		{
			action(element);
		}
	}
}

You don't need to re-implement the whole thing, just use Bootstrapper and override CreateContainer method there and create an instance of WindsorAdapter. The adapter will register necessary components for Caliburn framework so you won't have to register them like you do above (e.g. WindowManager, EventAggregator, etc.)

Hadi, I believe you are confusing Caliburn (http://caliburn.codeplex.com) with Caliburn.Micro (http://caliburnmicro.codeplex.com/). This gist shows how to hook up Castle Windsor as the container for your Caliburn.Micro apps. Caliburn.Micro does not provide an adapter for Windsor and CM's Bootstrapper does not have a CreateContainer method to override. This gist provides the core functionality of Caliburn 2.0's "Caliburn.Windsor.dll" for users of the lighter Caliburn.Micro framework.

Thanks for the comment though.

New to using Caliburn, so forgive me for this question, where in this bootstrapper do I wire up my dependencies for Windsor, lets say I have multiple implementations of the same interface and depending on certain criteria, say in the app.config I choose certain concrete implementations. I do this in my other projects and I'm trying to figure out where this goes using Calibrun.Micro and your bootstrapper.

Good question mark.

In Castle, the first registration wins (it becomes the default registration). If you want app.config registrations to win, you could modify ApplicationContainer::ctor() to look like this

public ApplicationContainer()
            : base(new XmlInterpreter(new ConfigResource("castle")))
{
    .... everything else stays the same
}

Here's a Castle sample you might find helpful:
https://github.com/NashDotNet/lab-dependency-injection/blob/master/src/Castle/CastleWithXmlAndCodeRegistration/Program.cs

If you want to add in-code registrations, you could put them in ApplicationContainer:ctor() alongside the IWindowManager and IEventAggregator registration (or at any point after that).

Hope this helps!
-Bryan

Mark, In Windsor I usually do this using IWindsorInstaller implementations to register my interface -> types with the container and on application start (in Caliburn in the Bootstrapper) I wire them using Container.Install(FromAssembly.This()) or equivalent. This will execution registration code partitioned in IWindsorInstallers at application start so you'll have a ready to use container. Hope this helps. *Hadi Eskandari * _E:_ H.Eskandari@Gmail.com | _T:_ +98-912-3351635 | \* *_W:_ http://www.hightech.ir _|_ http://hadi.es ``` [image: MCPD]<http://www.mcpvirtualbusinesscard.com/VBCServer/HEskandari/profile> ```

…

On Fri, Nov 18, 2011 at 2:44 AM, Mark Wilkinson < ***@***.*** > wrote: New to using Caliburn, so forgive me for this question, where in this bootstrapper do I wire up my dependencies for Windsor, lets say I have multiple implementations of the same interface and depending on certain criteria, say in the app.config I choose certain concrete implementations. I do this in my other projects and I'm trying to figure out where this goes using Calibrun.Micro and your bootstrapper. --- Reply to this email directly or view it on GitHub: https://gist.github.com/1127914

There is a SelectAssembly method that you could override in the bootstrapper that does the trick. Default implementation returns the entry assembly and Caliburn will look for View/View models there, but overriding this property you can return any number of assemblies containing your View and ViewModels, which Caliburn will use to look for View/VMs to create. Guess this addresses your current issue. Now to your original requirement, it is not a good thing to couple your code directly to the Container or similar usages that lead to using container in a Service Locator pattern. To resolve any required component from the container, simply inject one into the constructor of your view model. Wondering why that wouldn't work for you?

…

On Wed, Jan 18, 2012 at 8:04 PM, Mark Wilkinson < ***@***.*** > wrote: New question. Thanks for the help thus far. I'm running into an issue where external libraries or other project libraries I create need to be able to access the ApplicationContainer to resolve a dependency. They can't do this per-say if the castlebootstrapper and appcontainer are in the main project with the mainview, etc. So I moved the castlebootstrapper, applicationcontainer, and all views and viewmodels to a new library project, and only have kept the app.xaml in the main (what I consider main) startup project. Now when I run the app I get a "Cannot find view for YadaYada.Library.ViewModels.MainViewModel" The structure I have for the views and viewmodels is to have a Views folder and a ViewModels folder inside this Library project (exactly how it's demonstrated in intro to caliburn). There is a MainView that should correspond to the MainViewModel, and it's path is "YadaYada.Library.Views.MainView.xaml," etc. I realize I need to do something in the ApplicationContainer or Bootstrapper (I'm using the exact code above) to tell Caliburn to locate the Views inside this path, can you lead me in the direction to do this? thanks. -mark --- Reply to this email directly or view it on GitHub: https://gist.github.com/1127914

Thanks for the reply.

Yeah I deleted my question after finding the answer in the documentation about SelectAssembly.

Now, you mentioned the container. So if I have say a MenuBuilder that builds up a menu, with menu items, and I set the Action of one of the MenuItem clicks to open up a new window, I resolve that by injecting into this MenuBuilder the ViewModel of this window I want to open? If I get the viewmodel how do I then open up it's corresponding view?

-mark

When using Caliburn you hardly specify any views, you just open and display view models and Caliburn will find out which view it should create and bind to the ViewModel. Regarding how to inject something that you're going to use later, different containers have different strategy, you can inject Lazy<T> in some containers and use it later, or you can use Factory delegates or interfaces. The built-in conatiner of Caliburn does not support these scenarios, you'll have to use richer containers like Windsor or AutoFac.

…

On Wed, Jan 18, 2012 at 10:31 PM, Mark Wilkinson < ***@***.*** > wrote: Thanks for the reply. Yeah I deleted my question after finding the answer in the documentation about SelectAssembly. Now, you mentioned the container. So if I have say a MenuBuilder that builds up a menu, with menu items, and I set the Action of one of the MenuItem clicks to open up a new window, I resolve that by injecting into this MenuBuilder the ViewModel of this window I want to open? If I get the viewmodel how do I then open up it's corresponding view? -mark --- Reply to this email directly or view it on GitHub: https://gist.github.com/1127914

I'm using Castle Windsor.

In the past using basic MVVM I would give the ViewModel a Show() method on it's interface, that Show() method would then call the Show() of the View, and the IView was injected into the constructor of the ViewModel.

Do need to do that with Caliburn. Check out tutorials on my bloghttp://hightech.irand see if that helps. Castle Windsor 3.0 supports Lazy<T> and version 2.5 supported delegate and factory interfaces.

…

On Wed, Jan 18, 2012 at 10:42 PM, Mark Wilkinson < ***@***.*** > wrote: I'm using Castle Windsor. In the past using basic MVVM I would give the ViewModel a Show() method on it's interface, that Show() method would then call the Show() of the View, and the IView was injected into the constructor of the ViewModel. --- Reply to this email directly or view it on GitHub: https://gist.github.com/1127914

Looked through Payroll solution 1 and 2, couldn't compile probably because of lacking DevEx products.

But I noticed you're using what looks like Caliburn and not Caliburn.Micro as your bootstrapping was done in the App.xaml.cs.

I couldn't find where you fire up a new view or UI in the code in the Payroll part 2 solution. That's really all I need to get to, presenting a new window or view.

Main window has a ViewModel that is derived from PresenterManager, this class knows how to display ViewModels. In ShellViewModel you just call this method on base class (also there's an extension method) to display your ViewModel. There isn't very difference between Caliburn or Caliburn.Micro in this sense. * *

…

On Thu, Jan 19, 2012 at 12:43 AM, Mark Wilkinson < ***@***.*** > wrote: Looked through Payroll solution 1 and 2, couldn't compile probably because of lacking DevEx products. But I noticed you're using what looks like Caliburn and not Caliburn.Micro as your bootstrapping was done in the App.xaml.cs. I couldn't find where you fire up a new view or UI in the code in the Payroll part 2 solution. That's really all I need to get to, presenting a new window or view. --- Reply to this email directly or view it on GitHub: https://gist.github.com/1127914

If you register components by instance, it probably means the component uses singleton lifestyle, but you alraedy have an instance of the component that you want to use. So I'd register it using: container.Register(Component.For<IMyService>().Instance(myserviceInstance).LifeStyle.Singleton); So now that you have the interface and registered it as singleton, you can inject it into ctor/property as before. If you are registering multiple classes with the same interface but with different name (not sure if that is even possible in Windsor) there are other tricks you can use to decide on runtime which implementation of the interface you want to resolve. In general, having direct dependency to container and using Resolve method everywhere is something you probably want to avoid.

…

On Sat, Jan 21, 2012 at 2:07 AM, Mark Wilkinson < ***@***.*** > wrote: To Bryan or Hadi, How do I get to the container to resolve something myself? If I Register a dependency in Windsor with the .Named("someName") how do I get back to the container to resolve that instance? --- Reply to this email directly or view it on GitHub: https://gist.github.com/1127914

Thanks Brian. This is what I was looking for.

Any idea about how the ViewModel release management should be handled?

When I have to show a new window, I am first using Castle's container to resolve the new ViewModel, and then invoking the ShowWindow method of WindowManager to take care of the rest.

But how I can make sure this is released from the container after the window is closed?

Accounting to the document, even though the LifeStyle of view model is set to transient, it's still necessary to invoke Release when the window is closed.
http://docs.castleproject.org/Default.aspx?Page=LifeStyles&NS=Windsor&AspxAutoDetectCookieSupport=1#Transient_5