3

In a quest to reduce the dependencies in my projects, I now have everything depending on and implementing interfaces, and they are glued together by an IoC container. This means projects need only to have direct references to such interface libraries.

However, if you don't specify the project as having a reference to the implementation (even though you don't need it at compile time) the implementation libraries are not included with the executable or in the setup project.

Is in a way Visual Studio promoting bad practices by requiring explicit references when they are not needed? Is it possible to have the dependencies only to the required interfaces and in this case what is the best method to get the implementation libraries available?

Otávio Décio
  • 73,752
  • 17
  • 161
  • 228

3 Answers3

2

Is in a way Visual Studio promoting bad practices by requiring explicit references when they are not needed?

Not really. Your issue is one of deployment, not building.

Deploying an application and building it are separate things - if you have a good deployment strategy, you will be deploying implementations where they belong.

Is it possible to have the dependencies only to the required interfaces and in this case what is the best method to get the implementation libraries available?

The easiest way is indeed to reference the implementation assemblies. This will definitely make building and running locally as easy as F5, but do you really want that? To be honest, if you and your team have the discipline to only code to interfaces, that's all you need (and there are static analysis tools like nDepend that help with ensuring that remains the case).

One way forward is to create a deployment script that will deploy all dependencies whether local or elsewhere.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • Thanks, @Oded. I agree, however given the stock templates in VS you need to include these dependencies. What would you recommend as a deployment strategy other than what comes out of the box? – Otávio Décio Jun 27 '12 at 19:09
  • [WiX](http://sourceforge.net/projects/wix/) is a good deployment toolset for scripting builds and deployments. – Adam Houldsworth Jun 27 '12 at 19:14
  • @AdamHouldsworth - probably a good reason to move to WiX even more so now that VS11 won't have setup projects. – Otávio Décio Jun 27 '12 at 19:15
  • Just to be fair, they include a free stripped down version of InstallShield. Well you know how good that is... – Otávio Décio Jun 27 '12 at 19:17
1

No. It is simply the minimum they need to do in order to give developers working code without them having to do anything extra (aside from hitting F5) or for all references to be added by default (which would likely be a mess and slow on older hard discs.

For local development builds, you can simply have a post-build step on the relevant project to copy the DLLs to the main working directory. Just make sure the project is added to the active configuration to be built, other wise you'll go through a whole annoying debug session on the post-build only to realise there was no-build... lol

VS 2010. Post-build. Copy files in to multiple directories/multiple output path

Copy bin files on to Physical file location on Post Build event in VS2010

For full-scale application deployment, you'd likely be looking at Visual Studio setup projects at a bare minimum, but more ideally something like WiX or another deployment tool-set.

Community
  • 1
  • 1
Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
1

Visual studio does not require these references, but your IoC container does. When adding a reference to the project, its binaries are automatically included in the output folder, which is necessary for your IoC container to glue the code together. There are other ways to get these binaries to the output folder than referencing their projects in Visual Studio - perhaps a post-build step?

Nikola Anusev
  • 6,940
  • 1
  • 30
  • 46