title: Visual studio not copying content files from indirectly referenced project
body: <p>I have the following project structure:</p>
  
  <pre><code>Library1 &lt;--[project reference]-- Library2 &lt;--[ref]-- Executable
  --------                          --------            ----------
  ContentFile                      .cs files           .cs files
  .cs files
  </code></pre>
  
  <p>All project references have CopyLocal = true.</p>
  
  <p>When I build the project, the <code>ContentFile</code> gets copied to <code>Library2</code>'s output directory, but not to <code>Executable</code>'s output directory, meaning that the executable is missing <code>ContentFile</code> when the application runs.</p>
  
  <p>Why is the content file being copied to <code>Library2</code>'s output directory, but not <code>Executable</code>'s? Is there a way to also copy it to the latter (I'd like to do that without build events because I'm sure people will forget that)?</p>
  
  <p>I am looking for a reasonable and <em>maintainable</em> solution; one that requires minimal effort when adding new projects <em>or</em> new indirectly referenced content files, so that it is as unlikely as possible to simply forget doing it.</p>
  
  <p>Using Post-Build events (like <code>xcopy ../Library/bin/Debug/SomeDll.dll bin/Debug</code>); and manually setting the output directory of projects to <code>$(SolutionDir)/bin/...</code> instead of the default (per-project basis), have both quickly become a huge mess. Adding the content files as links in the "main project" was too tedious as well. It would be fine if C# had the same default setting for the output file as Visual C++ does (that is, <code>$SolutionDir/$Platform/$Configuration</code>), but it doesn't.</p>
  
  <p>I've also considered not using the standard MSBuild procedure at all and write a custom build target (like using gcc in Atmel Studio), but I didn't get far at all. Furthermore, I want Visual Studio's standard "Build" and "Debug" commands to work as they usually do.</p>
  
  <hr>
  
  <h2>UPDATE:</h2>
  
  <p>Here is more detail on what I am doing.</p>
  
  <p>I have a solution with an <code>Executable</code> project. Furthermore, there is a bunch of projects that you could call <code>Plugin</code>s. <code>Executable</code> references all those <code>Plugin</code>s via a managed project reference.</p>
  
  <p>Since the plugin projects are tailored to the executable, but may have reusable components, the main functionality is often implemented in an <code>External</code> project, leaving the <code>Plugin</code> project a mere wrapper (not always though).</p>
  
  <p>Said <code>External</code> projects sometimes use native DLLs provided by third parties. Those DLLs are then added to the <code>External</code> project as a content file and have <code>Copy to output dir</code> set to <code>Copy always</code>. So the structure looks like the diagram above:</p>
  
  <pre><code>External &lt;---------------[is not aware of]--------------------+
  --------                                                      |
  .cs files &lt;--[reference]-- PluginWrapper &lt;--[reference]-- Executable
  "Native DLL"               -------------                  ----------
                             .cs files                      .cs files
  </code></pre>
  
  <p>The weird thing is, that the "Native DLL" gets copied to <code>External</code>'s output directory (obviously), <strong>as well as</strong> <code>PluginWrapper</code>'s, <em>but not</em> <code>Executable</code>'s.</p>
  
  <p>The developer's workflow would then be to write an <code>External</code> that works as a completely isolated entity (they <em>are</em> being reused very often), wrap it with a <code>PluginWrapper</code>, and then only add a project reference to the <code>PluginWrapper</code> to <code>Executable</code>. I find it odd that this is apparently such an uncommon thing to do.</p>
  
  <p>I thought that maybe editing <code>Executable</code>'s MSBuild target XML (to also include indirectly referenced content files) could have solved the problem.</p>
  
  <p>I might want to look into adding the DLLs to the projects as embedded resources as suggested, but embedding native DLLs like that seems weird to me. In the end, changing the developer's workflow by stripping the '[is not aware of]' from the above diagram and adding a project reference to <code>External</code>, as Brenda Bell suggested, might be the most sensible solution, even if not ideal.</p>
  
  <p><em>Update 2</em></p>
  
  <p>Note that the embedded resouce idea may not work in all cases. If it is necessary to place a dependency in the executable's directory (not cwd or anything), then this may not work because of missing administrator privileges in the installation folder (to unpack the file from the embedded resource). Sounds weird, but this was a serious issue with one of the 3rd party libraries we were using.</p>