views:

595

answers:

5

I have a solution with several projects in it. Let's say

project A depends on projects B and C

project B depends on project C

When I run my solution on the local machine VS builds each project once and it takes 1 minute. However, on our build machine it takes about 4 minutes to build and, as I can understand from the MSBuild logs it goes like this:

build A -> build B for A, build C for A

build B -> build C for B

So it builds some projects several times... How can I speed up the build process?

P.S. It's not a question of 3 extra minutes, I just wonder why is it so different from my local machine build?

A: 

Maybe like our's, your build server is a virtual machine (10x at least slower).

Also TFS (and maybe others), does a fresh checkout on build, so it will have to build all the projects regardless.

leppie
We do build in virtual machine - HyperV - and there is little difference when comparing to normal machine... Once we moved the project to (virtual) SCSI disk that is. HyperV IDE disks are sloooow.
bh213
+2  A: 

I am not sure about your build order. Sometimes TeamBuild can look like it is building projects over and over but it is building for different configurations. Take a look and make sure you have not defined multiple FlavorsToBuild.

Also, if you don't want to do a fresh check out and rebuild every time, you can define this at the bottom of your TFSBuild file.

<PropertyGroup>
    <IncrementalBuild>true</IncrementalBuild>
</PropertyGroup>-->

Put that right before the </Project> tag.

Vaccano
By the description in MSDN I can see that it is exactly what I need: an incremental build. Still just adding this tag to the config file didn't change anything... Do I need to go further and mess with Inputs/Outputs? Or maybe something is wrong with the paths in my environment so msbuild can't see the previously built files?...http://msdn.microsoft.com/en-us/library/ms171483.aspx
Yacoder
A: 

Are you using the /maxcpucount switch? There may be a difference in number of processors between your local machine and the build machine. This setting can also be different between your msbuild file and the visual studio setting which could also explain the difference you're seeing in build times.

JNappi
+1  A: 

This sample seems to work for me. TestLib.Extra depends on TestLib. If I change something in TestLib, both projects will build. If I change only in TestLib.Extra, only that one will build, and if I don't change anything at all, they will just report Skipping target "CoreCompile" because all output files are up-to-date and so on.

<Target Name="Build">
  <MSBuild Targets="Build" Projects="TestLib\TestLib.csproj" />
  <MSBuild Targets="Build" Projects="TestLib.Extra\TestLib.Extra.csproj" />
</Target>

The trick is to use the "Build" target of the projects, rather than "Rebuild". The difference between these is essentially the same as the difference between the "Build" and "Rebuild" commands in the build menu in Visual Studio.

Edit

This works well also if the projects are included in a solution file, and you specify the solution to build instead:

<Target Name="Build">
  <MSBuild Targets="Build" Projects="TestLib.sln" />
</Target>
Fredrik Mörk
Hmmm... I'm using the "SolutionToBuild" command. Like in MSDN: http://msdn.microsoft.com/en-us/library/ms181718(VS.80).aspx
Yacoder
@Yacoder: SolutionToBuild is not a command; it merely specifies files and associates them with the name "SolutionToBuild". This name will be used elsewhere in the msbuild script to perform the actual build. That's where you might be able to do what I show in my sample.
Fredrik Mörk
A: 

I do this as follows. It is somewhat complicated custom build system but the basic idea is.

  1. The dlls which are reused in many solutions are build to a known folder. This is achieved my using a msbuild project file that builds these common dlls.
  2. When building other csproj files in a solution we copy the csproj files then use xslt manipulation to replace the project references with dll refernces for those common dlls.
  3. The build scripts then build these changed csproj files using custom msbuild project files we maintain corresponding to each solutions. We don't build .sln files. These custom project files is a itemgroup of .csproj files in correct dependency order.

Maybe this can help you in achieving what you want.

Pratik