I'm working on a project with different assemblies (imagine a printer-module, a imaging-module etc.). In this project, all interfaces are declared inside one Interfaces-assembly (imagine Interfaces.dll with interfaces IPrinterModule, IImagingModule etc.).
Since I'm a cowboy-coder ;) I have to ask the SO-community if this really is best practice or how this can be done in a better way?
That sounds good to me - having a separate assembly for interfaces is quite common, especially for systems that do a lot of plugins.
Most likely you are using these interfaces to create loosely-coupled bridges between orthogonal components (good for you, by the way). The only way to do this in a truly modular way is to have a separate assembly for those interfaces so that every type that either implements the interface or references it is actually using the same interface type. Really your only other option would be to compile everything in the entire system into one assembly.
If there are circular references then keeping all your interfaces in separate assembly will help you. I've read many code samples (from microsoft, codeproject and other sites) in last few days while studying about workflow, the interface is declared in the assembly implementing it.
Like IPrinterModule will be declared in the assembly which implements
We have adopted a similar approach. You definitely want to separate the interfaces from their (current) implementation, so it is easy to provide different implementations in future. Martin Fowler has described this as the Separated Interfaces pattern.
If the interfaces have dependencies on each other (does an IPrinter return an IImageXXX?) then you really need them in the same assembly to avoid circular build dependencies.