问题
When building managed code Visual Studio correctly (and recursively) copies dlls of referenced managed projects to the output folder of the project being build.
However, if one the of those references is a managed DLL that depends on unmanaged dlls then these unmanaged DLLs are not copied to the output folder, even though their corresponding projects in the same solution and are listed as dependencies of the managed DLL.
I realize that this problem can be resolved by having all projects use the same output folder. We already do that for most projects, but we prefer to keep unit test output folders separate, causing the above issue for unit tests that use a managed Dll with unmanaged dependencies.
The solution we are using right now is a pre-build event to copy the necessary DLLs but this wastes time and is error-prone as it needs to be repeated for every project that uses the managed DLL.
I would therefore like to know if there is a way to get the build system to understand that it should always copy the unmanaged dependencies of the managed DLL whenever it decides to copy the managed DLL?
回答1:
One workaround seems to be to add another node to the managed DLL project, naming the unmanaged DLL and setting the Build Action = "None", and Copy to Output Directory = "Copy if Newer".
Edit: For building a C++/CLR project, I think this would work:
Add the node, and set its build tool to Custom Build Tool. Then, in the Custom Build Step page, set the Command to copy $(InputPath) $(OutDir) and the Outputs to $(OutDir)\$(InputFileName). Looks like that should work.
来源：https://stackoverflow.com/questions/1980114/how-to-get-visual-studios-build-system-to-understand-unmanaged-dependencies-of-m