Best practice for implementation assembly deployment to bin folder?

[Scott_M]

We structure our MVC web projects in a VS2010 solution like so:

1. DLLProjectA.Int

2. DLLProjectA.Impl

3. DLLProjectB.Int

4. DLLProjectB.Impl

5. DLLProjectC.Int

6. DLLProjectC.Impl

.

.

N. MyMVCProject

DLLProjectB may use items from DLLProjectA but only through dependency injection / interfaces.  We currently register all of our castle windsor dependencies via web.config on our mvc web application.  We use post build events in MyMVCProject to ensure that IMPL (implementation) projects are copied to the mvc web app's bin folder.    Using post build events to copy IMPL assemblies the web app bin folder requires artificial project dependencies to make everything work properly.  This can be tedious and error prone.  Is there a better way to deploy IMPL assemblies to the consuming app's bin folder?  Is it safe to replace post build events with direct project references from the MVC app to each of the IMPL DLL projects or does this establish tight coupling?   Would like to hear what other castle windsor users are doing.

thanks

[Tomek Pluskiewicz]

I usually also have the Web App split in two:

1. MVCProject - controllers, filters and stuff. This has dependencies to the "Int" projects

2. MVC Web App - this has dependencies to *everything* it needs. 

This is safe because in this projects there is virtually no code in the Web App project. Only views, global application class and possibly some MembershipProvider class so the risk of jeopardizing the n-tier architecture is low and deployment is a breeze

There is also a second solution. You could consider merging the Impl and Int assemblies and hide implementations by having those classes internal. Configuring any mature DI is then best by using configuration modules (installers in Windsor). You could say that this causes your assemblies to rely on your DI container but let's face it, you aren't going to switch to another one during your project's lifetime with 99% certainty. And with Windsor you still can use XML configuration to override injection defaults (for example for different deployment environments or temporarily mocking not yet implemented services)

I am using Monorail by the way, but that should not make much of a difference.

Regards

Tomasz

[Jason Meckley]

I use the same approach as Tomasz using an logical layered approach, not a physical layered approach.

[gusgorman]

Hi Scott,

The solution I have used is to have a "DI" project which has all the
dependency injection config, and has references to all the necessary
interface and implementation projects. The webapp then has a reference
to this, which seems to ensure that the implementation dlls are copied
to the web apps bin folder.

regards,
Jordan.