tfs - Incremental Builds issue in Team Foundation Server

Question

When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:

• When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.

Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:

Build (TFS Build), only what is changed

Followed a couple of other sources.

• IncrementalBuild property in TFSBuild project
• Incremental builds in TFS

Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.

But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.

Please help me to achieve the desired build output.

Answer 1

Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).

This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.

You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.

PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.