I have a Visual Studio solution with a number of C# application projects.
Solution/ A/ B/ C/ Installer (WiX)/
Some of these executables need to be able to run others. For example, A needs to be able to run B and C. This is easy once the entire package is installed, since the executables will all get installed to the same location. However, I am unsure how to find B.exe
from A.exe
when I am running the programs from inside Visual Studio, i.e., when I am testing and debugging.
How do I get the correct path, no matter if I running from Visual Studio or after installing the program fully? I have some ideas, but I am a bit frustrated with execution, and I'm hoping it's easier than it currently seems. I am comfortable editing the *.csproj
files manually if that's what it takes.
Possible solution 1
I could put the paths in the App.config
files. However, there are problems:
- The files would need to be different for debug and release versions. This doesn't look easy. An answer on Stack Overflow recommends XSLT, which is somewhat pathological in its complexity and I especially don't want to learn yet another language just to solve such a simple problem.
- I would need to edit the file before it gets included in the installer, which is possible (reference) but requires yet more code.
Possible solution 2
I could put the necessary paths in plain text files that are created using post-build steps, but I don't know enough batch scripting to be comfortable with this.
Possible solution 3
Somehow copy B.exe
into the output directory for A, so B.exe
is always in the same path relative to A.exe
. This would be annoying, since there are already post-build steps which copy a bunch of dependencies for B.exe
, and the files would need to be copied again during A's build process.
Possible solution 4
Somehow adjust the build process so there is only one output directory shared between all projects in the solution.
Non-solutions
I'd like to keep the solution so that it works after checking out a fresh copy of the repository from version control, which means that environment variables or command-line parameters won't work.