1

I'm considering enabling:

Build in parallel

I'd like to know how the build is happening in Visual Studio locally, with the theory that if it's building fine locally in parallel I should be safe enough in VSTS.

In ye'olden days building in parallel was something to be enabled with msbuild command line voodoo and in my experience with complex projects it rarely seemed to use the other CPU cores.

But in Visual Studio 2017, it's a lovely simple and I now have a nice greenfield project (happy days):

maximum number of builds

Can I tell from Visual Studio's build output how many projects actually ended up being built in parallel to give me confidence in the VSTS setting?

Alex KeySmith
  • 16,657
  • 11
  • 74
  • 152

1 Answers1

2

Sure, refer to these steps to change MSBuild output verbosity (In the same window of your screenshot):

  1. Tools=>Options
  2. Select Projects and Solutions=>Build and Run
  3. Choose Normal in MSBuild project build output verbosity

Then the build log in VS output window will be like this:

1>------ Rebuild All started: Project: MVCCore20, Configuration: Debug Any CPU ------
2>------ Rebuild All started: Project: ConsoleApp1, Configuration: Debug Any CPU ------
3>------ Rebuild All started: Project: ConsoleApp2, Configuration: Debug Any CPU ------
4>------ Rebuild All started: Project: ConsoleApp3, Configuration: Debug Any CPU ------
2>Target CoreClean:
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\bin\Debug\netcoreapp2.0\ConsoleApp1.deps.json".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\bin\Debug\netcoreapp2.0\ConsoleApp1.runtimeconfig.json".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\bin\Debug\netcoreapp2.0\ConsoleApp1.runtimeconfig.dev.json".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\bin\Debug\netcoreapp2.0\ConsoleApp1.dll".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\bin\Debug\netcoreapp2.0\ConsoleApp1.pdb".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\obj\Debug\netcoreapp2.0\ConsoleApp1.csprojResolveAssemblyReference.cache".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\obj\Debug\netcoreapp2.0\ConsoleApp1.csproj.CoreCompileInputs.cache".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\obj\Debug\netcoreapp2.0\ConsoleApp1.AssemblyInfoInputs.cache".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\obj\Debug\netcoreapp2.0\ConsoleApp1.AssemblyInfo.cs".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\obj\Debug\netcoreapp2.0\ConsoleApp1.dll".
2>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp1\obj\Debug\netcoreapp2.0\ConsoleApp1.pdb".
2>Target GenerateTargetFrameworkMonikerAttribute:
2>  Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
4>Target CoreClean:
4>  Deleting file "D:\1.0_Starain\1.0_Work\4.8_VSO\1.1_Projects\2017\MVCCore20\ConsoleApp3\bin\Debug\netcoreapp2.0\ConsoleApp3.deps.json".
2>Target CoreCompile:

The number 1, 2, 3, 4 means processes.

On the other hand, it adds /m parameter to MSBuild command if check the option of Build in Parallel in VSTS build task, so the number processes are per to the number of processors on the computer, if you want to use custom value, you need to un-check that option and specify /m:X parameter in MSBuild Arguments input box.

starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53
  • Great tip thanks! I had a feeling it was going to be in the build output, I made the mistake of turning on detailed and it blowing my mind :-) I presume when the numbers exceed the number of cores it is a process count (guessing process isolation of some sort)? – Alex KeySmith Oct 05 '17 at 08:09
  • Wish I knew this gem back in the mega .sln days, the CPU usage hinted it wasn't in parallel but I bet some parts were. – Alex KeySmith Oct 05 '17 at 08:10