TeamCity build always deletes and regenerates the AssemblyAttributes.cpp and AssemblyAttributes.cs files in the buildTmp folder.

Hi,

the build temp folder is supposed to be clearable after each build, and will usually be cleared afterwards. The work/checkout directory are the directories where it's expected to retain the information for longer times, unless you explicitly request to have them cleared (via a clean checkout) or TeamCity determines that a clean checkout is needed because the directory contains elements that shouldn't be there.

If you split builds through multiple build configurations, modules that haven't changed should not be rebuilt, they shouldn't even trigger a build at all, reducing the time spent on the whole process. Maybe that can help?

> modules that haven't changed should not be rebuilt

Correct, but they do get rebuilt because the temp files needed by MSBUILD for .NET C# and C++/CLI projects get deleted.

We worked around this problem by adding the following to ALL of our .vcxproj and .csproj files.

<TargetFrameworkMonikerAssemblyAttributesPath>$([System.IO.Path]::Combine('$(IntermediateOutputPath)','$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)'))</TargetFrameworkMonikerAssemblyAttributesPath>

https://stackoverflow.com/questions/11888275/how-can-i-make-teamcity-take-advantage-of-msbuilds-incremental-build-support

Thanks for sharing your workaround. For the sake of clarity, there are two factors at hand here, and what I mentioned is slightly different. I'm not fully sure this will apply to your exact scenario, but I think pushing it out here could help somebody looking for help on the topic.

If you are building several modules/libraries within a single build, TeamCity will not automatically detect whether there are changes in some of them. It will treat the three of them as a whole, as detecting this is handled at the VCS Root level in the configuration. Once TeamCity decides that a build needs to happen, it will trigger the whole build, and will delegate the task of building to the build runner, which will take the decisions on what to do. If you have worked around this issue by adding the content to the csproj files, then this is probably your case. An example, you would build library1, library2 and executable1 in the same project or in 3 different steps within the same build configuration. The build will be delegated to the VS/MSBuild runner, and it will run the build. It's still possible that TeamCity is overly conservative and rebuilding everything here, but this would be an issue with the specific build runner, and I'd recommend following the steps here for debugging: https://confluence.jetbrains.com/display/TCD18/Common+Problems#CommonProblems-BuildworkslocallybutfailsormisbehavesinTeamCity

What I mentioned about rebuilding is different. You can split the multiple libraries/executables in multiple build configurations, and restrict what files to track via checkout rules. If you have 3 different build configurations for 3 different libraries, even if they are of the same project, as long as the checkout rules exclude the library folders properly, TeamCity will detect which code has changed during their regular VCS checks, and it will only trigger the builds that are required. If you have a final build that collects all the artifacts and packages everything via artifact + snapshot dependencies, it should only trigger builds that require rebuilding. It would also be able to build the multiple configurations in parallel.

All in all, to not rebuild modules/projects within a build configuration, it will fall to the build runner to handle it based on the incoming changes, and it might require specific setup for it.

>All in all, to not rebuild modules/projects within a build configuration, it will fall to the build runner to handle it based on the incoming changes, and it might require specific setup for it.

100% this is correct. The problem for us was that TeamCity was overriding the %TEMP% folder, then after MSBUILD creates those .cpp/.cs files and does a build, TeamCity deletes them, therefore causing a rebuild the next time, even if no other source files for the project(s) have changed. Anyway, we worked around it.