When using IoC containers, the calling application should ideally be responsible for configuring all dependencies.

A well-structured system will demand dependent objects as constructor parameters. How you invoke those constructors is independent of StructureMap or any other technique, but can only be specified at the point at which the "top most" object is used. Separation in this way will allow applications to inject dependencies in whichever way they desire and gives you that warm fuzzy feeling you can only get from having great separation of concerns.

I m not entirely sure what you mean by a "default" implementation in the context of your library. Your "default" implementation (configured by your StructureMap registry) will be the instance you get back when you ask StructureMap for an implementation of a given interface (presumably some kind of IRepository in your case), without specifying any other criteria.

For you, you will want this instance to be configured as your NHibernate implementation. Presumably this implementation already lives in the Library.Data.NHibernate namespace as your "NHibernate Repository". You shouldn t need to create any other implementation unless you want to change your IRepository implementation to something else.

I had the same question some time ago and finally i ended creating a registry class on each project and calling them in cascade.

I ll update with some code when i get home.

Update

I had 3 projects (Web, Services and Data) but i did not want to add a reference to Data in my Web project for example, so what i did is that every project is responsible of registering it s own Interfaces.

For example, In my Web project i created the class WebRegistry that not only register its own types but also calls the ServicesRegistry class in my Services project and so on.

WebRegistry:

public class WebRegistry : Registry
{
    public WebRegistry()
        {
            ObjectFactory.Configure(x =>
            {
                //call to ServicesRegistry in my services project
                x.AddRegistry(new ServicesRegistry());

                //Register your web classes here
                ForRequestedType... blablablabla

            });

        }
}

ServicesRegistry:

public class ServicesRegistry : Registry
{
    public ServicesRegistry()
    {
        ObjectFactory.Configure(x =>
        {
            x.AddRegistry(new DataRegistry());

            //Register your services classes here
            ForRequestedType... blablablabla
        });

    }
}

And finally the DataRegistry:

public class DataRegistry : Registry
{
    public DataRegistry()
    {
        ObjectFactory.Configure(x =>
        {
            ForRequestedType blablbabla....

        });
    }
}

I think this way everything is completely idependant and you only need one call to the webregistry in your global.asax to configure the entire application:

/// <summary>
/// 
/// </summary>
public class Bootstrapper
{

    /// <summary>
    /// 
    /// </summary>
    public static void ConfigureStructureMap()
    {
        ObjectFactory.Initialize(x =>
        {
            x.AddRegistry(new WebRegistry());
        });
    }


}

Global.asax:

    protected void Application_Start()
    {

        Bootstrapper.ConfigureStructureMap();


    }

Inversion of control configuration can be done in one of two places: in the calling assembly or in another assembly.

If you want to do it in the calling assembly (which couples it to the IOC tool), just do it in Global.asax.cs or in a class called there.

If you want to do it in another assembly, use an HTTP Module, like this: http://codecampserver.googlecode.com/svn/trunk/src/DependencyResolution/DependencyRegistrarModule.cs