How do I get a smooth debug experience in Visual Studio 2008 when using dependency injection?

What are the best practices around providing a smooth debug experience in Visual Studio 2008 when using dependency injection (DI)?

Specifically, suppose I have a solution with 3 projects:

MySolution: - ConsoleApp - ServiceInterface - ConcreteService

ConsoleApp has a reference to the ServiceInterface project, and uses a DI container to resolve the concrete type (from ConcreteService project).

When I start debugging, ConsoleApp will not be able to load the concrete type unless the ConcreteService.dll is present in the ConsoleApp bin\debug directory.

So the question is, how do I get 开发者_开发问答the ConcreteService.dll into ConsoleApp's bin\debug folder?

Some options I've thought of are a post-build script, adding a project reference in ConsoleApp to ConcreteService and copying the dll by hand.

There are some pros/cons to all of these approaches, so I'm curious to see if there are other approaches and if not, which approach people prefer.

Just add a reference to the concrete implementation.

Incidentally, it's perfectly OK architecturally to have the interface and implementation in the same assembly. You may have a good reason for not doing so, but people seem to shy away from this instinctively but for no good reason.

You could change the output directory of each project to the same directory. I've used MySolution\Debug for debugging DI projects to avoid adding references.

Addressing the first comment

What if you have multiple applications that use DI to get at the same dependencies? For example if I have a common data access layer used by multiple applications?

Odds are it's ok to dump everything together in the same debug folder for a solution. You'll only be debugging one application at a time and so long as you test your Release build, you should be fine.

You could also create different build configurations for the various applications in your solution and set the output folders to MySolution\ConfigurationXDebug (or something like it) for each configuration. This has the added benefit where you can explicitly choose to build the appropriate projects but is more work to setup.