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. I thought that maybe editing Executable's MSBuild target XML (to also include indirectly referenced content files) could have solved the problem. I find it odd that this is apparently such an uncommon thing to do. 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. 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.
So the structure looks like the diagram above: External <-+ Those DLLs are then added to the External project as a content file and have Copy to output dir set to Copy always.
Said External projects sometimes use native DLLs provided by third parties. 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). Executable references all those Plugins via a managed project reference. Furthermore, there is a bunch of projects that you could call Plugins. I have a solution with an Executable project. Furthermore, I want Visual Studio's standard "Build" and "Debug" commands to work as they usually do. 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. 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. Adding the content files as links in the "main project" was too tedious as well. instead of the default (per-project basis), have both quickly become a huge mess. Library/bin/Debug/SomeDll.dll bin/Debug) and manually setting the output directory of projects to $(SolutionDir)/bin/. 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. 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)? 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. I have the following project structure: Library1 <- Library2 <- ExecutableĪll project references have CopyLocal = true.
0 kommentar(er)
