In a web project, or any final project that employs dependency injection (could be WPF or Silverlignt application, even classic ASP.NET), all binaries that are used should be made available.
Imagine you have Lib1.dll
and Lib1.Impl.dll
, respectively an API library and a concrete implementation of the API. Now, in the web project you rely on dependency injection to provide you with concrete implementation of the interfaces from the Lib1.dll
. You may never happen to use a class from Lib1.Impl.dll
directly in that application. Still, the DI framework needs to access the Lib1.Impl.dll
in order to instantiate the dependencies.
Depending on the DI framework and the supported capabilities of loading dependencies, you should provide them accordingly. It seems straightforward to have them all in the bin folder, or referenced directly by the final project - that is probably the reason your project works when you provide the implementation dll-s in the bin folder. Since, however, this goes against the considerations of decoupling, you may have to look at alternative approaches to dynamically load dll-s - by physical location for instance. I am sure Unity supports mechanisms for this, since Modularity in Enterprise Library allows for bootstrapping modules from a filesystem location.
I must say, though, while I mentioned decoupling and keeping the references separate, this is not an issue if you have them all referenced in the final tier of the project hierarchy (the web application), as long as you do not have code that causes coupling in that application.