Using IncrediBuild with DevEnv.exe vs MSBuild.exe

Question

I use Xorax IncrediBuild to build Visual Studio 2013 (or later) solutions and projects, they're mostly .vcxproj with a bunch of .csproj ones.

It took me a little bit of digging, but I've learned that:

• When IncrediBuild is used with the regular Visual Studio, it uses the Devenv.exe by default.

• Since version 5.0, BuildConsole.exe supports a new switch: /UseMSBuild to specifically instruct IncrediBuild to use MSBuild's build engine instead of the default Visual Studio's DevEnv.

So, in case of Visual Studio projects, there are two modes available:

• BuildConsole.exe MyProj.vcxproj which uses DevEnv.exe

• BuildConsole.exe MyProj.vcxproj /usemsbuild which uses MSBuild.exe

I'd like to learn if there are any differences between using the two engines.

I have made some tests and observed that:

• IncrediBuild "Initializing..." phase takes slightly longer in case of DevEnv.exe.

• BuildConsole.exe generates different output, obviously.

• No (or insignificant) difference in build performance.

In case of building individual C/C++ native projects (.vcxproj) as well as whole solutions (.sln), what are advantages and disadvantages of using DevEnv.exe versus MSBuild.exe?

Answer 1

** disclaimer: I work at IncrediBuild **

We've determined together with Microsoft that in order to get builds that behave in the same manner as building from within Visual Studio (without IncrediBuild), DevEnv should be used. MSBuild executes builds in a slightly different manner than VS both in the build output it produces and in the way it behaves when executing custom steps and some other minor things. If a user wants IncrediBuild builds to behave in the same manner as he is used to when building from Visual Studio, the default way should be used (IncrediBuild executing DevEnv). If a user is used to execute his builds using MSBuild, whether from the command line or through TFS, the UseMSBuild switch should be used. We wanted to allow users to choose the way they would like IncrediBuild to work depending on the way they are used to do that, same as Microsoft supporting both DevEnv and MSBuild.

Additional comments:

1. The initialization stage is indeed longer when using Devenv, since devenv loads and parses the solution and .vcxproj files in a different manner than msbuild. The more Projects a solution has – the longer this phase should take. The increase of time it takes this phase to complete usually greatly offset by the speed increase in the actual build time – when building several projects at the same time.
2. Devenv is highly recommended for our Predicted Execution feature which can provide up to 20% of additional build acceleration due to the above way of work which would be not possible using MSBuild.

Answer 2

Microsoft is pretty explicit about it:

For build-related tasks, it is now recommended that you use MSBuild instead of devenv. For more information, see MSBuild Command Line Reference.

A note in the Devenv documentation since VS2010, the first version of VS that started supporting building C++ projects with MSBuild and also changed the default project file extension from .vcproj to vcxproj.

The wisdom of this kind of advice can only be inferred when they are not explicit about it. One you ready saw, Devenv.exe is a pretty heavy process with many DLL dependencies, it takes a while to get going. Another you could fret about with the way you are doing it now, original guidance was to use Devenv.com instead of Devenv.exe. Those dependencies are also troublemakers, the kind that tend to get in the way or just plain fall over when Devenv.exe runs in an unusual runtime environment like a service. Sample story-from-hell is this Q+A, three answers and none look correct. There are others.

Plain advice is to use the recommended way.