5

Premise
I have a Visual Studio 2015 solution containing different VC++ projects.
Some of them (EXE and some DLLs) have the $OutDir set to default "$(SolutionDir)$(Configuration)\" (i.e. "C:\MySolution\Debug\").
For some other projects (DLLs), I need to change the output path to a sub-directory of the "default" $OutDir (i.e. "C:\MySolution\Debug\Pieces\".

Example directory tree: 

  C:\MySolution\Debug\  
    MyProgram.exe  
    Dependency.dll  
    .\Pieces\  
      MyPiece1.dll  
      MyPiece2.dll

Constraints
the "Pieces" DLLs depends on a third-party Dependency.dll (through NuGet package), which I cannot modify.

Usual solution
The usual way for this is to change the $OutDir project setting for "pieces" projects, but this will also force their dependencies to be output in the same sub-dir.
This is not wanted and also created problems in debugging and packaging of the entire solution.

What I tried so far
I tried to: 1. keep the $OutDir the same for all projects
2. change the "pieces" $TargetName to "Pieces\$(ProjectName)"
This seems to work (both MyPiece*.dlland Dependency.dll are correctly placed and debugging is fine), but unfortunately Visual Studio generates the following warning:

warning MSB8012: TargetName(Pieces\MyPiece1.dll) does not match the Linker's OutputFile property value (MyPiece1). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

This warning is somewhat confusing, because the %Link.OutputFile in the project settings looks correct:
$(OutDir)$(TargetName)$(TargetExt) => C:\MySolution\Debug\Pieces\MyPiece1.dll

Question
What is the correct approach to solve my problem?
How do I force Visual Studio to output some of the generated files in a different path, but still having their Nuget dependencies in the "default" $OutDir?

I've searched the web and StackOverflow already, but I can't find a suitable answer.
Note: my problem is not related to upgrading a pre-VS2010 solution (as in Microsoft official notes on warning MSB8012 after solution upgrade and asked on StackOverflow).

Community
  • 1
  • 1
roalz
  • 2,699
  • 3
  • 25
  • 42
  • 1
    Have you considered using a post-build event on each of the Pieces projects to simply `copy` the compiled DLLs and PDBs to the paths where you need them? It's a pretty low-tech hack, but it's often good enough. – Sean Werkema Mar 09 '17 at 18:24
  • @SeanWerkema Yes, post-build 'move' files is one of the options I've investigated, but unfortunately it creates errors in the automated build, especially when activating parallel builds. – roalz Mar 10 '17 at 10:03
  • Are you sure your project dependencies are set up correctly? If you get errors during parallel builds that you don't get with serial builds, you may have a broken/invalid dependency graph. There's no reason anything that depends on those copies should be invoked before they've completed, either in a manual build or in an automated build. – Sean Werkema Mar 10 '17 at 15:29
  • @SeanWerkema Errors are clearly referring to the copy file operation. Errors are more frequent if I use the VS GUI available post-build events, less frequent if I manually add MSBuild Copy Tasks in the .vcxproj files. – roalz Mar 10 '17 at 15:47
  • I'm not sure what form of `copy` you're using, but this is what I use, and it works. In the _pre-build_ event of the _consumers_ of a library, I have this command: `copy /y "$(SolutionDir)SomeLibrary\bin\$(Platform)-$(Configuration)\SomeLibrary.*" "$(ProjectDir)bin\$(Platform)-$(Configuration)"` You might need to tweak the paths in your case, but I have never had a failed build using that pattern. (Notice also that it's `SomeLibrary.*` — that copies the `.pdb` files as well, which makes debugging a lot easier.) – Sean Werkema Mar 10 '17 at 17:51

0 Answers0