Scheduled build launches an hour early on TFS 2013 (after installing Update 3 or 4)

There’s new information in this issue. Please read the updates at the bottom of the article.

We use our own TFS server and were using TFS 2013 Update 2 up until last Tuesday. We have several build definitions for my current project, and most of them are scheduled at a specific time, because we have specific times for automatic deployment. Up until Tuesday, everything seemed to work well and the Builds ran at the specified time (both before and after Daylight Saving Time applied).

And then I installed Update 4… :)

The issue

After installing Update 4, our scheduled builds ran an hour early. Of course I checked both the time on the server and the time the build was scheduled for: these were fine. I looked at the Update 4 documentation, but couldn’t find anything related. I did see however the build server report its time setting as UTC +01:00, and the build definition stating UTC +02:00.
Next up was searching the web, which pointed me to an article on Scheduled build launched 1 hour earlier. As a comment on this article, which is from July last year, Microsoft employee Mario mentions the issue is fixed in the (at that time) RC of the Summer Update. He also mentions:

Once you install that Update on the server please recreate/re add the build definition and the database will now respect the right times.

Visual Studio 2013 Update 3 & 4

Since we were using Update 2, I looked at the documentation of both Update 3 and Update 4. And if you go to the New technology improvements in Visual Studio 2013 Update 3 chapter and look at the Fixed issues paragraph you find this for Team Foundation Server:

Scheduled builds may run an hour early after daylight saving time.

This led me to believe the update Mario was talking about July last year was part of Update 3. Which might be the cause of our issues.

The solution – Quick & Dirty

To get our builds to run at the scheduled times, we used a real obvious and Quick & Dirty solution: we shifted the scheduled times of the builds an hour, so they run at the time we expect them to run, not the time they are scheduled to run (??!?!?).
There are some downsides to this solution, like the builds not running at their scheduled time, but an hour early. That’s not logical. So you should document / communicate it well. Another downside is I expect the build won’t run at the right time after Daylight Saving Time.

The REAL solution

I created a new build definition that was scheduled at a specific time. And it ran at the specified time. Since Update 3 solves this issue, I expect it to run at the same time after Daylight Saving Time.

So the only REAL solution is to re-create your build definitions.


I think (but am not sure) the following scenarios apply:

Build definition created in Build definition running in Result
Update 2 Update 2 Works fine (?)
Update 3 / 4 Update 3 / 4 Works fine
Update 2 Update 3 / 4 Trouble in paradise


For details about the updates, have a look at the Description of Visual Studio 2013 Update 3 and Description of Visual Studio 2013 Update 4.
You can find the Connect article over at Scheduled build launched 1 hour earlier.

UPDATE April 9 2015 16:15

It seems like it’s enough to edit (something small in) the build definition and save it to TFS again. The builds for which we shifted the time now build at the shifted time.
I’ve set the time for the scheduled builds to their original value and hope I can add a second update here tomorrow saying all is well…

UPDATE April 10 2015 09:45

Just to confirm, like Bryan MacFarlane states below: changing something small and saving your build definition is enough to fix this issue. So the impact is minor. Emoticon met brede lach

By |April 9th, 2015|TFS|1 Comment

Error comparing historic versions of a TFS source controlled file

These files are not text files and cannot be opened in the comparison window.

When working with Visual Studio 2012 on our current project, the error ‘These files are not text files and cannot be opened in the comparison window.’ shows up every now and again. I’ve tried several things to solve this problem.

Here’s the one that works:

  • Close Visual Studio
  • Navigate to your version of the ‘c:\users\{username}\AppData\Local\Temp\’ folder
  • Delete the TFSTemp folder
  • Restart Visual Studio and try again. You should be good to go!

Hope this helps.

HowTo: sign out of Visual Studio Online (when deleting cookies won’t help)

When you have more than one Microsoft Account that you use regularly, you might recognize the scenario where your Visual Studio keeps you signed in to Visual Studio Online… with the wrong account. You keep getting messages that you don’t have access rights. Restarting Visual Studio, rebooting and even clearing all (Visual Studio) cookies doesn’t help. Here’s a quick fix:

  1. Open Visual Studio
  2. Open the Visual Studio web browser (under View, Other Windows, Web Browser)
  3. Go to Visual Studio Online
  4. Click sign out

You should be good to go now!

Hope this helps.

Error: The Path ‘path’ is already mapped in workspace ‘workspace’

Just a quick little post today: I got the error “The Path ‘path’ is already mapped in workspace ‘workspace'” when I connected to a new Team Foundation Server and tried to map my workspace today. I had connected to a Team Foundation Services project a while back to get some shared code, but I already removed the workspace and the server binding. Even though Visual Studio didn’t see any other bindings, mapping my workspace to the same folder the previous TFS binding was mapped to served me this error.

The quick solution: manually edit (or remove if you don’t have any other bindings) the file VersionControl.config, which can be found under %AppData%LocalMicrosoftTeam Foundation4.0Cache

Hope this helps.

HowTo: Disable specific Code Analysis rules for a Team Build

Thanks to the MSDN forums (and specifically one Hua Chen), I found a way to disable specific code analysis rules for a team build. In this post I’ll combine the steps I followed earlier with the description given at the MSDN forum. I’ll start out with some steps earlier on in the process: how to quickly get a list of all the code analysis rules you want to disable (without having to type it all yourself ;) ).

  1. Start Visual Studio and create a new project

  2. Open the properties for the project and navigate to the ‘Code Analysis’ tab

  3. Set the code analysis rules the way you want them, and save the project (you don’t have to enable code analysis: the settings are saved anyway)

  4. Close the project/solution

  5. Open the .csproj file in a text editor like Notepad or UltraEdit

  6. Find the tag named CodeAnalysisRules and copy the value of that tag, which looks something like this:

    You now have a list containing all the rules you do not want enforced.

Now for the real deal: how to disable specific code analysis rules for a team build.

  • Open the TFSBuild.proj file in a text editor (double clicking the file from the source control explorer will open it in Visual Studio, which works fine as an editor)

  • Find the PropertyGroup tag containing the RunCodeAnalysis tag

  • Set the RunCodeAnalysis tag to an appropriate value (I used Always to override individual project settings)

  • Add a tag named CodeAnalysisRules, and paste the rules you copied in the steps numbered 1 to 6 above

  • Find the Microsoft.TeamFoundation.Build.targets file at the Team Build Server. It is typically located in C:Program FilesMSBuildMicrosoftVisualStudiov8.0TeamBuild

  • Open the .targets file, find the CoreCompile target and copy the entire target

  • Paste the CoreCompile target in the TFSBuild.proj at the end of the project file, before the </Project> tag

  • Find the following task in the CoreCompile target, this is the second task from the end of the CoreCompile target

    <!– Build using MSBuild task –>
              Condition=” ‘@(SolutionToBuild)’!=” “
              Targets=”Build” />

  • Import your CodeAnalysisRules to the task in the Properties attribute (see the red part):

    <!– Build using MSBuild task –>
              Condition=” ‘@(SolutionToBuild)’!=” “
              Properties=”Configuration=%(ConfigurationToBuild.FlavorToBuild);Platform=% (ConfigurationToBuild.PlatformToBuild); SkipInvalidConfigurations=true;VCBuildOverride=$(MSBuildProjectDirectory)TFSBuild.vsprops;FxCopDir=$(FxCopDir);OutDir=$(OutDir);ReferencePath=$(ReferencePath); TeamBuildConstants=$(TeamBuildConstants);$(CodeAnalysisOption);CodeAnalysisRules=$(CodeAnalysisRules)
              Targets=”Build” />

That’s all of it. The rules you selected not to run (and pasted in the CodeAnalysisRules tag) will not be executed during the next build. Hope this helps!

By |September 4th, 2007|HowTo, MS Build, TFS|1 Comment

Disable specific Code Analysis rules for a Team Build

After searching a bit, I found a way to disable specific Code Analysis rules for a team build. Or at least I thought so… The RunCodeAnalysis tag in my build.proj file is set to ‘Always’ to override the individual project settings, and I added the ‘CodeAnalysisRules’ tag to exclude some rules as a test. (See below for a part of the build.proj file.) I ran a few builds, but the tag doesn’t seem to do what is supposed to. But when you use that tag in a project file, Visual Studio does recognize it as a valid tag… 

Unfortunately the build seems to execute all the rules, including the ones I tried to exclude by putting them in the CodeAnalysisRules tag with a ‘-‘ before them. I’m trying to find out if it is possible to exclude specific rules through the build file. I know it is possible to do so by putting the stuff in the CodeAnalysisRules tag my project file, but with a solution of 98 projects, this is not realy an option. ;)
I’ll keep you posted. And, as always, if you have any idea: drop me a line.

Snippet build.proj file:


Edit 1
I tried Jan’s suggestion (see the comments) and moved the ‘-‘ sign from in front if the Microsoft name to behind the #. This did not result in any rules being ignored either. So, unfortunately, our build still checks all rules, including the ones we don’t want it to check.
By the way, I know I can set Code Analysis rules as a check-in policy, and migrate those settings to the solution, but at this point it’s not possible to check out al of the 98 projects: several colleagues have projects checked out, and we’re working towards a deadline, so …

Edit 2
I also tried the suggestion David Kean posted over here, but to no avail. This might work for a project, but does not when entered in a TFS Build project. It looks like I will have to change the code analysis for all projects separately, in stead of being able to set it once for all projects in a build/solution. :(

By |August 31st, 2007|HowTo, MS Build, TFS|1 Comment