C# and IoC transitive dependencies removed

Question

I have a solution in which I use IoC (windsor). The projects in the solution are as follows:

1. Interfaces - Holds all the interface contracts I'll use.
2. IoC.Installers - Holds all the installers for my dependencies (has reference to impl. and interfaces)
3. IoC - Holds a singleton class that holds the IoC container. The class performs the initialization process of the container.
4. Console - The project that uses the IoC to resolve dependencies (has reference to interfaces an IoC)

The problem: Because the IoC project doesn't directly use the IoC.Installers project, it is omitted from the build process on the Console project, hence no installers are found during the initialization process.

The workaround: In the IoC project I added a static constructor that directly initiates an installer from the IoC.Installers project and uses it (I do a GetType() on the instance I make)

Problem with the workaround: I wanted to create some generic container holder that I could move from solution to solution without the need to fix my hack.

Is there a better way to force the IoC.Installers dll to be copied to the bin folder without the hack? The final aim is to create a nuget the wraps castlewindsor and tries to find all the installers in the solution and install them

I'm adding a link to a git repo in which I made a project that reproduces the problem (it contains the work around as well)

Thanks!

Precondition

Related: #9502104 – Chronometry

Your composition root (the startup path in your application, in your case your console application) usually references all other projects in the solution. What problem are you trying to solve by preventing the console application from referring the other projects? – Chronometry

@Chronometry I want to avoid referencing implementations and other things that the startup project should not know about. My final goal is to create a Common.Windsor nuget that I could initiate by steps: 1. initiate by finding all installers. 2. referencing a config file. – Precondition

Please read the related question I linked to. It typically makes no sense in preventing the startup project from knowing about other assemblies; it should know ALL about the other projects. If your case is different from some reason, please update your question and explain clearly why your case is different from what is explained in the related question. – Chronometry

@Chronometry yes, it makes sense. An IoC container consumer should not have direct dependencies to the libraries, only to the "common" library (where the interfaces are placed) and to the IoC container library. It's the IoC container library the one which should have the references to the libraries it can resolve. His problem is caused by – Beam

Answer 1

As discussed in Is "Copy Local" transitive for project references?, your only options are

1. Add a fake usage of the libraries in your IoC container library;
2. Add a post-build XCOPY step to copy the libraries to the application output folder;

If you choose #2 and don't know how to do it, have a look at the MSBuild guide to understand how to edit MSBuild scripts (you'll have to edit the <Target Name="AfterBuild" /> element of your application's .csproj).

Beam

Answer 2

Copy the IOC.Installers assembly manually in the console directory when you are building (eg post-build on success), and instead of installing from assemblies in the application, install from the assemblies in a directory:

container.Install(FromAssembly.InDirectory(new AssemblyFilter("dir/of/console")));

There is also a file mask parameter which can speed up the filtering:

container.Install(FromAssembly.InDirectory(new AssemblyFilter("dir/of/console", "*.installers.dll")));

Stem