Some excellent answers here already, but let me focus on what you mentioned to be your main issue, getting the build working on another machine.

This should be mostly orthogonal to any of the other issues you experience with the current project / solution structure. If that is your top priority, I would recommend to solve this first, without cleaning up the overall structure too much. Merging everything into one solution is nothing which brings you nearer to your main goal.

As @JohnWu mentioned in a comment, start with a build script. This script should

• initialize some environment variables required (maybe detecting in which folders the required tools are installed)

• check if required drive folders are available (or other prerequisites)

• run MSBUILD in the correct order for the four solutions, with the correct configurations (and include detection if one of the build fails). To give you an idea how this could look like, here is an excerpt of one of our build scripts:

   %MSBUILD% /m /p:Configuration=Release %MYFOLDER%\MySolution.sln >MyBuild.log if ERRORLEVEL 1 goto :displayerror find "0 Warn" MyBuild.log >nul: if ERRORLEVEL 1 goto :displayerror 

• copy all the EXE files, DLLs, documents, configuration templates required for the release process in one "Deploy" folder

Second, make sure you have some standard where the required build tools should be installed (for example, the folder where Visual Studio is placed). The build script can mitigate some differences between different environments, but you should not make things harder for it than necessary.

Now, your goal should be that you can checkout the whole source tree on a arbitrary machine, in some folder, run that script and get the build done.

For this, it is important that you eliminate all absolute path references from the VS projects. Every reference, every pre-build or post-build event should use relative paths, whereever possible. For this, it does not matter if you use "project references" or DLL references, both must be relative paths.

If you cannot eliminate all absolute references in some of the prebuild or postbuild events, you may utilize the environment variable initialization from the build script for this task. Just put these into a helper script of its own, and call that script where it is needed.

Finally, I would heavily recommend to make sure your projects don't contain any configurations not required. Use Visual Studio's configuration manager to find out about which configurations are there, and delete everything you don't need. For example, if you only need the standard "AnyCPU" config, make sure there are no "x86" and "x64" configurations any more (if you have different configs, Visual Studio tends to open "the wrong one" by default, and you may run into trouble when you run the next build by the IDE).

Some excellent answers here already, but let me focus on what you mentioned to be your main issue, getting the build working on another machine.

This should be mostly orthogonal to any of the other issues you experience with the current project / solution structure. If that is your top priority, I would recommend to solve this first, without cleaning up the overall structure too much. Merging everything into one solution is nothing which brings you nearer to your main goal.

As @JohnWu mentioned in a comment, start with a build script. This script should

• initialize some environment variables required (maybe detecting in which folders the required tools are installed)

• check if required drive folders are available (or other prerequisites)

• run msbuild.exe (or devenv.exe) in the correct order for the four solutions, with the correct configurations (and include detection if one of the build fails). To give you an idea how this could look like, here is an excerpt of one of our build scripts:

   %MSBUILD% /m /p:Configuration=Release %MYFOLDER%\MySolution.sln >MyBuild.log if ERRORLEVEL 1 goto :displayerror find "0 Warn" MyBuild.log >nul: if ERRORLEVEL 1 goto :displayerror 

• copy all the EXE files, DLLs, documents, configuration templates required for the release process into a "Deploy" folder (and not more).

I would recommend to make sure you have some standard where the required build tools are installed (for example, the folder where Visual Studio is placed). The build script can mitigate some differences between different environments, but you should not make things harder for it than necessary.

Now, your goal should be that you can checkout the whole source tree on a arbitrary machine, in some folder, run that script and get the build done.

For this, it is important that you eliminate all absolute path references from the VS projects. Every reference, every pre-build or post-build event should use relative paths, whereever possible. For this, it does not matter if you use "project references" or DLL references, both must be relative paths.

If you cannot eliminate all absolute references in some of the prebuild or postbuild events, you may utilize the environment variable initialization from the build script for this task. Just put these into a helper script of its own, and call that script where it is needed.

Finally, I would heavily recommend to make sure your projects don't contain any configurations not required. Use Visual Studio's configuration manager to find out about which configurations are there, and delete everything you don't need. For example, if you only need the standard "AnyCPU" config, make sure there are no "x86" and "x64" configurations any more (if you have different configs, Visual Studio tends to open "the wrong one" by default, and you may run into trouble when you run the next build by the IDE).

Some excellent answers here already, but let me focus on what you mentioned to be your main issue, getting the build working on another machine.

This should be mostly orthogonal to any of the other issues you experience with the current project / solution structure. If that is your top priority, I would recommend to solve this first, without cleaning up the overall structure too much.

As @JohnWu mentioned in a comment, start with a build script. This script should

• initialize some environment variables required (maybe detecting in which folders the required tools are installed)

• check if required drive folders are available (or other prerequisites)

• run MSBUILD in the correct order for the four solutions, with the correct configurations (and include detection if one of the build fails). To give you an idea how this could look like, here is an excerpt of one of our build scripts:

   %MSBUILD% /m /p:Configuration=Release %MYFOLDER%\MySolution.sln >MyBuild.log if ERRORLEVEL 1 goto :displayerror find "0 Warn" MyBuild.log >nul: if ERRORLEVEL 1 goto :displayerror 

• copy all the EXE files, DLLs, documents, configuration templates required for the release process in one "Deploy" folder

Second, make sure you have some standard where the required build tools should be installed (for example, the folder where Visual Studio is placed). The build script can mitigate some differences between different environments, but you should not make things harder for it than necessary.

Now, your goal should be that you can checkout the whole source tree on a arbitrary machine, in some folder, run that script and get the build done.

For this, it is important that you eliminate all absolute path references from the VS projects. Every reference, every pre-build or post-build event should use relative paths, whereever possible. For this, it does not matter if you use "project references" or DLL references, both must be relative paths.

If you cannot eliminate all absolute references in some of the prebuild or postbuild events, you may utilize the environment variable initialization from the build script for this task. Just put these into a helper script of its own, and call that script where it is needed.

Finally, I would heavily recommend to make sure your projects don't contain any configurations not required. Use Visual Studio's configuration manager to find out about which configurations are there, and delete everything you don't need. For example, if you only need the standard "AnyCPU" config, make sure there are no "x86" and "x64" configurations any more (if you have different configs, Visual Studio tends to open "the wrong one" by default, and you may run into trouble when you run the next build by the IDE).

Some excellent answers here already, but let me focus on what you mentioned to be your main issue, getting the build working on another machine.

This should be mostly orthogonal to any of the other issues you experience with the current project / solution structure. If that is your top priority, I would recommend to solve this first, without cleaning up the overall structure too much. Merging everything into one solution is nothing which brings you nearer to your main goal.

As @JohnWu mentioned in a comment, start with a build script. This script should

• initialize some environment variables required (maybe detecting in which folders the required tools are installed)

• check if required drive folders are available (or other prerequisites)

• run MSBUILD in the correct order for the four solutions, with the correct configurations (and include detection if one of the build fails). To give you an idea how this could look like, here is an excerpt of one of our build scripts:

   %MSBUILD% /m /p:Configuration=Release %MYFOLDER%\MySolution.sln >MyBuild.log if ERRORLEVEL 1 goto :displayerror find "0 Warn" MyBuild.log >nul: if ERRORLEVEL 1 goto :displayerror 

• copy all the EXE files, DLLs, documents, configuration templates required for the release process in one "Deploy" folder

Second, make sure you have some standard where the required build tools should be installed (for example, the folder where Visual Studio is placed). The build script can mitigate some differences between different environments, but you should not make things harder for it than necessary.

Now, your goal should be that you can checkout the whole source tree on a arbitrary machine, in some folder, run that script and get the build done.

For this, it is important that you eliminate all absolute path references from the VS projects. Every reference, every pre-build or post-build event should use relative paths, whereever possible. For this, it does not matter if you use "project references" or DLL references, both must be relative paths.

If you cannot eliminate all absolute references in some of the prebuild or postbuild events, you may utilize the environment variable initialization from the build script for this task. Just put these into a helper script of its own, and call that script where it is needed.

Finally, I would heavily recommend to make sure your projects don't contain any configurations not required. Use Visual Studio's configuration manager to find out about which configurations are there, and delete everything you don't need. For example, if you only need the standard "AnyCPU" config, make sure there are no "x86" and "x64" configurations any more (if you have different configs, Visual Studio tends to open "the wrong one" by default, and you may run into trouble when you run the next build by the IDE).