CODEWITHSUNDEEP
tfsmsbuild
Jon Davis
Jon Davis

Reputation: 6773

How to clear "changed" state in TFS for build schedule or change changeset time?

We have our projects configured with MSBuild script customization to modify the ApplicationVersion property in the project and copy that into the AssemblyInfo.cs file when the project builds. The problem is that we have TFS set up to run on a nightly schedule, with "Build even if nothing has changed since the previous build" unchecked. But since TFS itself is producing this version update, it will rebuild and increment every night. So this is sort of an infinite loop of our own design, but trying to figure out how to get out of it.

If the "changed since the previous build" detection is based on the history timestamp, ideally it'd be nice if when the version gets updated and commits to TFS it does it with a timestamp that precedes the build time. Is that even possible?

If the "changed since the previous build" detection is based on some boolean/bit flag, is there a way to reset it?

Using TFS 2012.

Upvotes: 0

Views: 137

Answers (2)

MrHinsh - Martin Hinshelwood
MrHinsh - Martin Hinshelwood

Reputation: 23444

I would suggest that you don't check the new version number into TFS. There is no value in having the version number in there.

I typically set the checked in assembly info numbers to all zeros. ( 0.0.0.0) and never update them except locally for the build.

This gives you the benefit of always being able to identify locally built DLLs.

Upvotes: 0

James Reed
James Reed

Reputation: 14052

I'm assuming that you're checking in the new version of the assemblyinfo.cs once it's been updated, and this is why TFS is queuing a new build. Have you tried adding a comment to the checkin of ***NO_CI*** This will definitely suppress a CI build but I'm not 100% certain if it will work in your scenario.

Another option is generating the version number via an algorithm rather then just incrementing a counter and checking it back in to Version Control. This circumvents the issue of a new build being triggered

i.e if your version number looks something like 1.2.3.4

Where 1 is Major (modified by a human not the build process)

2 is minor (also modified by a human)

the final 2 digits are then updated by an automated process.

You could use number of days since January 2000 for digit 3 (an arbitrary number but something that would change on a daily basis) and either the latest changeset number in Version Control or the total number of builds performed by TFS for digit 4.

This would fulfill 2 requirements, that version numbers are unique for a given build of an assembly, they always go up.

Upvotes: 1

Related Questions