Visual studio not copying content files from indir

Question

I have the following project structure:

Library1 <--[project reference]-- Library2 <--[ref]-- Executable
--------                          --------            ----------
ContentFile                      .cs files           .cs files
.cs files

All project references have CopyLocal = true.

When I build the project, the ContentFile gets copied to Library2's output directory, but not to Executable's output directory, meaning that the executable is missing ContentFile when the application runs.

Why is the content file being copied to Library2's output directory, but not Executable'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)?

I am looking for a reasonable and maintainable solution; one that requires minimal effort when adding new projects or new indirectly referenced content files, so that it is as unlikely as possible to simply forget doing it.

Using Post-Build events (like xcopy ../Library/bin/Debug/SomeDll.dll bin/Debug); and manually setting the output directory of projects to $(SolutionDir)/bin/... 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, $SolutionDir/$Platform/$Configuration), but it doesn't.

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.

---

UPDATE:

Here is more detail on what I am doing.

I have a solution with an Executable project. Furthermore, there is a bunch of projects that you could call Plugins. Executable references all those Plugins via a managed project reference.

Since the plugin projects are tailored to the executable, but may have reusable components, the main functionality is often implemented in an External project, leaving the Plugin project a mere wrapper (not always though).

Said External projects sometimes use native DLLs provided by third parties. Those DLLs are then added to the External project as a content file and have Copy to output dir set to Copy always. So the structure looks like the diagram above:

External <---------------[is not aware of]--------------------+
--------                                                      |
.cs files <--[reference]-- PluginWrapper <--[reference]-- Executable
"Native DLL"               -------------                  ----------
                           .cs files                      .cs files

The weird thing is, that the "Native DLL" gets copied to External's output directory (obviously), as well as PluginWrapper's, but not Executable's.

The developer's workflow would then be to write an External that works as a completely isolated entity (they are being reused very often), wrap it with a PluginWrapper, and then only add a project reference to the PluginWrapper to Executable. I find it odd that this is apparently such an uncommon thing to do.

I thought that maybe editing Executable's MSBuild target XML (to also include indirectly referenced content files) could have solved the problem.

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 External, as Brenda Bell suggested, might be the most sensible solution, even if not ideal.

Update 2

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.

Answer 1

Another option would be to embed ContentFile as a resource inside the Library1 assembly and extract it using Assembly.GetManifestResource().

See these links for more info:

http://www.attilan.com/2006/08/accessing-embedded-resources-using.html

http://blogs.msdn.com/b/alexdan/archive/2007/12/19/loading-embedded-resources-in-c-using-getmanifestresourcestream.aspx

Answer 2

EDIT:

You can put all content in a separate project, set all its entries to "content" and "copy always" and reference that project from External and Executable

-

IMO you're looking for embedded resource, not for content files.

When you compile Library 1 the content files are placed in its bin folder. When Library 2 is compiled the compiler recognizes referenced code and includes it (Library 1.dll) but the content files aren't recognized since they aren't mentioned anywhere in Library 2. The same goes when linking Library 2 to the executable.

If your content files are relatively small (icons, templates etc) and you don't envision need to edit them if you were to lose the source code then you can embed them as resources and provide a public method to return the contents, such as:

 public static Stream GetResourceContent(string rName){
     string resName = System.Reflection.Assembly
         .GetExecutingAssembly().GetManifestResourceNames()
         .FirstOrDefault(rn => rn.EndsWith("."+rName));
    if(resName!=null)
        return System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream(resName);
    else
        return null;
}

If your content is bound to change, such as templates etc, then consider including a copy with the executable project

Answer 3

One variation on Brenda's answer would be to add the Library1's content file(s) as Link(s) in the Executable project. You'd still have the entries in the project but you wouldn't need manage multiple copies of each file.

Answer 4

Add Library1 reference to the Executable project.