自动复制相关 DLL，无需二进制引用

Question

Visual Studio 2015, C# Console project + C# Library projects:

Is there a way to achieve automatically copying related project binary output to an output dir of a particular "master" project without using Project reference (and Copy local = True)?

I want to be able to maintain the exe-s and dll-s loosely coupled without the actual binary reference, but can rely on the related dll-s are always copied to the right output dir (eg Debug/Release).

Example:

• Master project: Console project named "Console"
• Related project: Library project named "Library"
• There is no need (and no will) to create binary reference from Console to Library, but we know we will need the Library DLL in the current dir while startup resolving Dependency Injection container components (in the EXE app).
• We want to automate the building process on the local machine.
• We want to easily add this kind of "reference" from another "master" projects (eg WPF GUI project), so the approach "Project dependencies + Build Events" isn't flexible enough.

Answer 1

I have only verified this solution on VS2017, but based on the date of the referenced MSDn article, it should work with VS2015 : use ReferenceOutputAssembly is your csproj. Sadly, this is a property that can only be added via manual edit of the csproj.

<ProjectReference Include="..\..\Calfitec\PglLibPAC\PglOdpm\PglOdpm.csproj">
  <Project>{261de855-9e8f-45de-b57d-fd4c7deb5f1b}</Project>
  <Name>PglOdpm</Name>
  <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>

See also: How to have a Project Reference without referencing the actual binary

This is the intended use of the feature:

Sometimes you want a project reference from project B to project A to indicate a build-time dependency, but you don't actually want assembly B to reference assembly A (maybe because it's a runtime-only dependency or loaded using reflection).

Answer 2

TL; DR; The fact that Copy local even appears tells me that Console has a direct Add Reference dependency which kinda defeats the purpose of DI. Just let Visual Studio do it's thing via Copy Local=true .

If:

1. Console has a Add Reference to Library
2. Console expects Library to appear in the same folder as Console at runtime
3. You don't have a large number of projects in your solution

...then you should just let Visual Studio do it's thing via Copy Local = true because Console has a direct dependency that must be solved and Dependency Injection (DI) doesn't even come into the equation. If you have a large number of projects, it can be shown to speed builds considerably if the copy happens once at the end but you didn't indicate this is your scenario.

If however:

1. The aim is to use dependency injection
2. Console does not have a Add Reference to Library
3. classes in Library are to be created dynamically via DI
4. Library is to be optionally deployed into a different folder than Console, perhaps a folder known as Plugins or DI

...then it's easier to have a Post Build step in one of your projects to copy dependant DLLs once to a single target folder. This is especially the case when developing plugins/DI for a large solution.

See < project >. Properties.Build Events.Post-build event command line

DI?

It sounds like you are wanting to use DI, but the appearing of Copy Local=true tells me that your program has a direct relationship to the library anyway. What's the point of DI? Your's is already strongly-coupled.