When you're using the MVC integration, it assumes that you're working in a web context. You will have trouble in unit test context (if that's where you're at) because there's no web context.
On each web request, you get a new lifetime scope that lives only as long as the web request. That's the "httpRequest" named scope. Controllers, for example, are automatically scoped to be an instance per request.
If your controllers, for example, have constructor parameters, those parameters should just resolve via Autofac without you manually specifying them. That's the whole point of the integration - you should only very, very rarely have to call DependencyResolver.GetService or any other methods like that.
If you have to call DependencyResolver.GetService to get some other class (like some non-controller class you need that, for whatever reason, you can't take in as a constructor parameter), then the Autofac dependency resolver will try to create a request scope before doing the resolution. In a web environment, that's no problem. In unit tests, it's tougher and requires more work. You'll need to plug in your own ILifetimeScopeProvider when you create the dependency resolver in unit tests. Your custom provider will have to create the httpRequest named scope.
This might be easier to understand if you just look at the source for the AutofacDependencyResolver. You'll see how the httpRequest scope is created:
If you find that you're having to pass parameters during resolution, then you're not really using dependency injection the way it was intended. You may need to add parameters during dependency registration, but you shouldn't need to pass parameters at resolution time.
For example, say you have a class that needs the current username:
public class UsernameConsumer : IUsernameConsumer
{
public UsernameConsumer(string username) { }
}
You have a couple of ways to solve that. First, you could do it during registration time:
That will resolve the value during resolution. If you need a more pluggable way to do it, you could do some redesign:
public class UsernameRetriever : IUsernameRetriever
{
}
public class UsernameConsumer : IUsernameConsumer
{
public UsernameConsumer(IUsernameRetriever retriever) { }
}
Then you can just register the appropriate types and Autofac will plug them in automatically.
Point is, it's best if you can use the DependencyResolver.GetService sparingly and try to avoid the parameter passing.
If all else fails and you absolutely have to pass parameters at resolve time, the note above about a unit-test-specific ILifetimeScopeProvider should get you past the exception.