[RESOLVED] Recompile Multiple Solutions

Is there any means to recompile many solutions in any automated fashion in both debug and release versions? Failing that, is there a setting such that you can recompile a project for both debug and release versions at the same time without needing to change the setting manually?

The background is kind of in the this thread, especially the third post:
https://www.vbforums.com/showthread....-Has-Gone-Nuts

All the plugins in this project are separate solutions. All of them need to reference a certain common dll. Something went wrong with that common dll. I have no idea quite what it was, but the results were bizarre, to say the least. A class within the dll has a property. It's had that property for years, and nothing has changed. In whatever the event was that prompted me to start that other thread, the property was 'lost'. Recompiling the common dll was not enough. Any plugin that referenced that common dll and made use of the class that had that property started reporting that the property didn't exist any longer. Recompiling the plugin would fix the issue.

So, VS has managed to get it's wires crossed, somehow. The three dozen projects that reference that dll all need to be recompiled, because, while they still have a reference to the common dll, and that common dll isn't just right, it hasn't changed in years, all those projects now think it's lost something that it hasn't lost.

The solution is easy enough: Every one of the projects has to be recompiled...maybe. Since the projects are all plugins, each is in it's own solution. Is there an easy way to recompile them all at once?

Additionally, it has always annoyed me that you have to select Debug or Release versions. I guess I can see that a person might want to make changes to one and leave the other alone (though only making changes to debug while leaving release alone, not vice versa), but I don't. I want to rebuild once time and get a fresh debug and release build. Is that option available?

I'm fairly certain that you cannot do this in VS but you can script MSBuild, so that's probably the way to go. It's not something I've ever done so I cannot offer more than that point in the (hopefully) right direction.

I don't know about choosing to build specifically Debug or Release from a script as the only time I used a script to build I always built with the current settings, which was for Debug, which is obvious from the last line of the batch file. I just listed all the executables that were built so the person running the script could do a quick spot check of the dates to verify they were all built in the last few minutes. If one or more of the executables were old you would know to scroll back up to look for the error output, or contact me and let me know.

The batch file simply made sure it had the latest source from svn, and then changed to the various sub directories and built the solutions. {edit: actually I guess I built the projects, not the solutions}
Don't know if it will help get you started. It was from a project a number of years ago which no longer exists.

Code:

---

@echo off
rem (this next comment line may no longer be applicable)
rem This batch file must be run from a Visual Studio Command Prompt (2010) so msbuild.exe and VS environment are setup
rem (the above comment line may no longer be applicable)
rem Now...
rem The WHERE and IF lines below remove the requirement of having to run this from a Visual Studio Command Prompt,
rem but, in case the two lines don't work for some reason, then note you should be able to still manually launch a VS command Prompt, if
rem Visual Studion (2010 or higher) is installed.

WHERE msbuild.exe
IF %ERRORLEVEL% NEQ 0 call "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"

svn update

cd SimControl
msbuild.exe SimControl.vbproj /t:rebuild

cd ..\GenericFlightModel
msbuild.exe GenericFlightModel.vbproj /t:rebuild

cd ..\FlightModelLauncher
msbuild.exe FlightModelLauncher.vbproj /t:rebuild

cd ..\AuxSimControl
msbuild.exe AuxSimControl.vbproj /t:rebuild

cd ..\ExternalFlightModelInterface
msbuild.exe ExternalFlightModelInterface.vbproj /t:rebuild

rem DisManager directory structure a bit different to the rest. project file is a directory lower
cd ..\DisManager
msbuild.exe DisManager\DisManager.vbproj /t:rebuild

cd ..\EO_IR_Sim_MBP
msbuild.exe EO_IR_Sim\EO_IR_Sim.vbproj  /t:rebuild


cd ..
Dir .\EO_IR_Sim_MBP\EO_IR_Sim\bin\Debug\EO_IR_Sim.exe .\DisManager\DisManager\bin\Debug\DisManager.exe .\SimControl\bin\Debug\SimControl.exe .\FlightModelLauncher\bin\Debug\FlightModelLauncher.exe .\GenericFlightModel\bin\Debug\GenericFlightModel.exe .\AuxSimControl\bin\Debug\AuxSimControl.exe .\ExternalFlightModelInterface\bin\Debug\ExternalFlightModelInterface.exe

---

As other said, use MSBuild in bat/cmd file. Put in the proper order build for each solution or project - build first assets that will be used in higher level projects.

To create release build use following parameter:

Code:

---

msbuild /p:Configuration=Release

---

You have to build twice if you want both Debug and Release versions so prepare batch file that builds single solution - first parameter is path to solution, second the version type (debug or release) and create the proper command. Add parameter for the top level "build" script where you can pass parameter if you want debug or build so you the script can pass it to single project/solution build one.

Script everything that you can automate, use git and build in separate directory or better - another computer (you can download and install only MS Build Tools there).

git clone in new directory will give you clean source tree so it is the starting point to get clean builds without strange errors. When you are ready with clean builds, you can create another script that will only git pull latest changes from repository and perform partial build of changed files so you will get much faster build times.

I have never had a reason to try this but thought it was intriguing how to perform both debug and release builds. My first thought was, MS Build.

With that mentioned and untested the following seems like good starting point.

Did some research and it seems item groups can be used to perform debug and release builds e.g. (from here)

Code:

---

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Solution Include="../**/*.sln">
      <Properties>Configuration=Debug;Platform=Any CPU</Properties>
    </Solution>
    <Solution Include="../**/*.sln">
      <Properties>Configuration=Release;Platform=Any CPU</Properties>
    </Solution>
  </ItemGroup>
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
  </PropertyGroup>
  <Target Name="Build">
    <MSBuild Projects="@(Solution)" BuildInParallel="true" Targets="Build" />
  </Target>
  <Target Name="Clean">
    <MSBuild Projects="@(Solution)" BuildInParallel="true" Targets="Clean" />
  </Target>
  <Target Name="Rebuild">
    <MSBuild Projects="@(Solution)" BuildInParallel="true" Targets="Rebuild" />
  </Target>
</Project>

---

Unsure about ../**/*.sln which appears to be a globbing pattern which if correct would mean the solutions are under a root folder.

Following the same path as above, the following introduces placement of compiled code in other folders.

I have certainly heard of MS Build, but never used it. Looks like I need to. Also looks like I can incorporate it into the utility project I built to move things around, so that would be good.

After looking it over, I realize that this solution would work...and I decided not to do it anyways. There are some rare times when it would be worthwhile, but those times...well, they've never happened yet, so I don't think it's worth it now. I only work on one or two projects at a time, and those I can manually compile to debug and release more easily than running some batch file from the command line. One thing about VS is that compiling sure is easy. Making up a batch file to recompile a bunch of them would make sense, I just realized that's not the way I'm working on things.

So, thanks for the answers. They did solve the problem as presented, I just decided the problem wasn't the right one.