TLDR: Using InjectionConstructors in Unity can give you singletons. Beware! (and TEST!)
So our tester at work spotted some InvalidOperationExceptions being logged from our data access library recently indicative of a DbContext being re-used across requests...
Digging into the registration showed quite a few instance of this sort of code:
container.RegisterType<IService, ServiceImplementation>(
new TransientLifetimeManager(),
new InjectionConstructor(new Dependency()));
Spot the mistake?
Passing an InjectionConstructor into RegisterType to specify which constructor on the ServiceImplementation class to use is fine...
Except that passing new Dependency() to the InjectionConstructor does not indicate that a new instance of the Dependency type should be created for each resolution of IService... instead it creates a singleton instance there and then that's subsequently shared across all instances of the IService. Which is bad.
Of course, for DBContext dependencies this is particularly bad - and is the source of the InvalidOperationException that was detected. It's an easy mistake to make, but one that's really hard to spot until you see those exceptions being logged.
The solution - use InjectionConstructor as it's intended:
container.RegisterType<IService, ServiceImplementation>(
new TransientLifetimeManager(),
new InjectionConstructor(
new ResolvedParameter<Dependency>()));
The ResolvedParameter clause says clearly that you're letting the container decide on the lifetime of Dependency.
For bonus points - and to prevent regressions - write tests that verify both that your composition root / container bootstrapper registers types with the correct lifetimes, and that where you've got DBContexts involved that you get a separate DBContext instance when you resolve two instances of IService.
Whilst the above is specific to the Unity IoC framework, you can be sure that all IoC frameworks will have a similar gotcha - so watch out for your registrations!
