I know it's late, but I just fixed this in our project and want to clarify on this.
The reason you end up thinking that you need module DLLs in the Shell folder is that you haven't copied all module dependencies to the module folder (and by all I mean dependencies of dependencies, which are easy to miss). When the runtime wants to resolve these dependencies, it looks in the module folder but fails, so it then looks in the app's execution directory (the Shell's directory), fails as well, and then, in a somewhat misleading way, reports this last location in the error that it throws. This is why you end up thinking that you need the DLLs in the Shell's directory.
Again, in reality, all you need is to make sure all module DLLs are in the module folder. The only exception is: if you have a DLL that both the module and the Shell are using (the Microsoft.Practices DLLs are good examples of this), then you only need the one in the Shell directory; there's no need to have it in the module's folder as well. This is because, as I explained above, the runtime will also look for DLLs in the executing directory.
The reason you end up thinking that you need module DLLs in the Shell folder is that you haven't copied all module dependencies to the module folder (and by all I mean dependencies of dependencies, which are easy to miss). When the runtime wants to resolve these dependencies, it looks in the module folder but fails, so it then looks in the app's execution directory (the Shell's directory), fails as well, and then, in a somewhat misleading way, reports this last location in the error that it throws. This is why you end up thinking that you need the DLLs in the Shell's directory.
Again, in reality, all you need is to make sure all module DLLs are in the module folder. The only exception is: if you have a DLL that both the module and the Shell are using (the Microsoft.Practices DLLs are good examples of this), then you only need the one in the Shell directory; there's no need to have it in the module's folder as well. This is because, as I explained above, the runtime will also look for DLLs in the executing directory.