C# class library project dependency injection bootstrap

Question

I recently used Dependency Injection pattern with Autofac as the IoC Container.

Normally, I would use it inside core application (Winform, WCF, WPF etc).

Currently I'm learning to create a class library project as a framework for my peer developers, and I tend to stick with the DI pattern since it allows me to unit test as I go.

How do I configure the IoC Container in a class library project without an entry point?

Should I just make something like :

public static void ConfigureLibrary() {
     //.. Do bootstraping here
}

and let core application to call it when the core app start?

How did libraries like the Patterns & Practices Enterprise Library or Spring.Net configured?

Solution 1

How did libraries like the Patterns & Practices Enterprise Library or Spring.Net configured?

Here is an interesting article from Chris Tavares about the subject.

Solution 2

How do I configure the IoC Container in a class library project without an entry point?

Generally the application should be the root for your service registrations. But yes, one may provide default-registrations in a library. Here is a blog-post I did some days ago how I and my team currently do.

Comments

[Samuel Adam]

Interesting indeed.. From what I am able to grasp pardon me for being a beginner, even libraries such as EntLib still requires the user to configure it using a facade, even the configuration is as simple as InitializeMyClassLibrary(). Is it the case?

[Steven]

AFAIK that's not the case. EntLib comes with a default configuration that can be used as is. There should be a default facade.

[Steven]

There is a default configuration thst you can override if you want to redirect the creation process to your own di container.

[Samuel Adam]

Well, I might be asking too much, but do you have any simple example on dependency injection in class library?

[Steven]

I can't really give you any examples, because it depends on your audience and your framework and the flexibility you wish to provide, which strategy you need. I think a good start is to have framework types with public default constructors that call into internal overloaded constructors (a pattern called poor man's DI). This allows you to test your code, while allowing users to easily use your framework. And depending on their needs, you can add factories in v2 or make those overloaded constructors public.