Common Service Locator and implementations of IDependencyResolver

I'm building a library for conversational natural language processing. In many ways it acts much like MVC3 in that it has Controllers and Action Methods. It also uses dependency injection in much the same way as MVC3 does when instantiating constructors for the Controller classes. The main differences being that an English sentence replaces both the URL and the form values of HTTP; routing is based on matching sentence structure; and the parameters passed in are the meanings of words and phrases used in the English sentence.

Currently it uses Autofac for Dependency Injection but I'd like to remove that dependency and allow callers to use any DI container.

If I use the P&P / Codeplex Common Service Locator project in my solution then callers would still need to provide their own implementations of IServiceLocator against the instance of that interface exposed by my engine. If I use IDependencyResolver from MVC3 instead there are at least existing implementations of the mapping from the various DI container to that interface.

Should I:-

1. use the Common Service Locator and force callers to implement the mapp开发者_如何学编程ing classes.
2. use the MVC 3 IDependencyResolver interface which already has mappings to other containers.
3. accept a object as the dependency resolver and duck type it to get the one method I need from it so I can use the MVC3 interface without even taking a dependency on ASP.NET MVC3.
4. other?

The Common Service Locator is, by definition, an interface assembly that never changes and doesn't need a specific version.

In addition all of the common IOC libraries now have implementations to connect to the Common Service Locator.

Thus option 1 is the best option and the risk of it breaking with a new release of the Common Service Locator is virtually zero.

Thanks to Philip Laureano for helping answer this.