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.
Add Library1 reference to the Executable project.