How can I make Visual Studio copy files before executing a built project

Question

I'm working on a game and a separate game engine(static library). The game copies includes and output from the game engine project via a pre-build script that I have set up in CMake.

When I'm changing code in the engine and want to test it; I run the game project. If the game project doesn't need recompiling though; the new lib files from the engine project will never be copied into the game project (I have set up pre-build events for copying before compiling the game project) and thus the changes wont take when I run the game.

This is annoying and has mislead me while debugging several times and I would therefore like the lib files to be copied every time the game project is started to ensure that they are always up to date.

I don't want to add a dependency from the engine project to the game project and therefore I cannot use a post-build script in the engine project to do this.

I have also looked into running a .bat file through the Debugging->Comand project setting in VS like they suggest here: How to run some script\excutable befure start debugging in VS2015?

This only works for release builds however since the debugger won't attach when starting through a .bat-file.

The batch code I've tried using for starting the generated .exe is:

• start Absolute/Path/To/Generated/File.exe
• call Absolute/Path/To/Generated/File.exe
• Absolute/Path/To/Generated/File.exe

The only fully working solution that I have come up with is executing the script through the source code of my game project. I would like to do this outside the source though since I want to be able to copy my CMake to a new project and have all the problems already dealt with.

Edit: Since there seems to be some confusion about my use case I will explain it further. I want it to be possible to develop the game and the engine separate of each other and therefore, the game project repository has copies of the engine project's outputted libs. I can't solve the issue 100% by pointing to the engine project's output directory in the game project because of the possiblity of the following situation:

1. Changes are made to the engine code and the project is recompiled.
2. Changes are made to the game code and the project is recompiled (Script for copying lib files trigger).
3. Changes are made to the engine code again and the project is recompiled.
4. When testing the changes to the engine; the game project does not require a recompile (So no scripts trigger and no copying occurs) and it is run with the new lib files from the engine project's output directory to test the changes made in both projects.
5. Everything works and the engine code is pushed to the engine repo and the game code is pushed to the game repo along with what the developer mistakenly thinks are the newest engine lib files.
6. The game repo is now in a state where it doesn't run without access to the engine project.

---

TL;DR:

Can I somehow (through Visual Studio or CMake preferably) trigger a copy of a bunch of files every time a project is started through Visual Studio?

Answer 1

Turning my comments into an answer

Your Problem

I was able to reproduce your problem and unfortunately even the direct call of the executable in a batch file (cmd or powershell) like Absolute/Path/To/Generated/File.exe does create a new process (which means your debugger won't automatically attach to this new/dynamically created process).

So there is no simple script based solution that will allow for copying the shared library dependencies at the moment you "Start Debugging (F5)" your executable.

This can be tested with some simple test code (waiting until a Debugger is attached and then triggering a break-point):

main.cpp

#include <Windows.h>

int main()
{
    while (IsDebuggerPresent() == FALSE);
    DebugBreak();
}

CMakeLists.txt

cmake_minimum_required(VERSION 2.4)

project(HelloWorld)

add_executable(HelloWorld "main.cpp")

start.ps1

.\HelloWorld.exe

Configuration Properties/Debugging (VS Project)

Command:            C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Command Arguments:  -ExecutionPolicy Bypass -File $(ProjectDir)\start.ps1
Working Directory:  $(TargetDir)

Now you can only attach to the new process manually. I've also tried the following powershell script:

start.ps1

Start-Process -FilePath "HelloWorld.exe"
Debug-Process -Name "HelloWorld

But you still need to select the debugger to use. Possibly the ReAttach Visual Studio extension could help to automate the process or you could start from Attach Debugger to multiple processes via powershell as a base, but I haven't tried this.

Alternatives I've used before ...

Two simple approaches I've used before for testing an executable with an external DLL (a scenario like the one you describe in your question):

1. Set the executable output path of your game project to build into the output path of your engine project. So if you start debugging you will always have the latest engine libraries.

   See CMAKE_RUNTIME_OUTPUT_DIRECTORY which can also be set from cmake command line

   > cmake -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=.... 
   

2. Set the executable's debugger Working Directory to the output path of your engine project.

   See your VS project's Configuration Properties / Debugging

   Or for setting this from within CMake VS_DEBUGGER_WORKING_DIRECTORY target property

Don't use "Binary Delivery" in CMake based Open Source Project

The question is also why you need to copy or deploy the (pre-)build files of your library to/with your executable?

The problem would be that you need to deliver libraries for "Platform + Compiler + Architecture + Configuration" for all possible combinations one could use CMake to generate a build environment for.

And you at least also need to deliver the header files (if the interface contract is not part of the library itself, e.g. as for managed code). If you then add program data base .pdb files, you would also need the source files to be able to debug into the library. This would summarize to your complete git package.

Generally I would recommend to read cmake-packages from CMake's doku and e.g. take a look at "Code Review: Basic CMake C++ project structure" or Making cmake library accessible by other cmake packages automatically