Due to an unidentified problematic reserved build, one of our build agent stops to function properly. Although the build agent is obviously with a Ready state and not running any workflows (the build tasks), it simply doesn’t give any responses to the build service. Hence any queued builds failed to start. So I tried to delete all the build agents/controllers under my control and rebuild them all from scratch. However, I failed to do that due to the same problem you can find in this post. http://sleepcanwait.blogspot.com/2010/07/cannot-remove-build-agent-from-build.html.

The solution in that post sounds like very straightforward; however, I can’t use it because I simply have no access to the data tier.

So I tried to rename the controller/agents to resolve this issue. This makes sense, right? considering the names must be something Key related in the data tier. If we can rename them, then they should not be treated as reserved anymore.

It turns out my guess was right. After renaming the names for the controller and agents, I can successfully delete them and rebuild them.

Now the build runs again like a charm.

Why the problematic reserved build is still an interesting question, though.

The Reliable Sessions feature of WCF has bothered me for a while because I thought I have never really understood it before I read this great post written by the original feature owner for it. Go read it if you are also interested in this stuff.

“TCP at the SOAP level”, a very simple but enough conclusion for the Reliable Sessions of WCF.

MSDN has articles about these two compiler switches. However, people have been always confused by the statements in this article. What does that exactly mean? Following are some experiment results for your references.

BTW, here is a great post that covers more details around this topic.

Hope this helps,

Command	PDB?	DebuggableAttribute
Csc Program.cs	No	No
Csc Program.cs /debug	Yes	[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.EnableEditAndContinue | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]
Csc Program.cs /debug+
Csc Program.cs /debug:full
Csc Program.cs /debug:pdbonly	Yes	[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
Csc Program.cs /optimize	No	No
Csc Program.cs /optimize+
Csc Program.cs /debug /optimize	Yes	[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]
Csc Program.cs /debug:pdbonly /optimize	Yes	[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Here we go.

Here is a link to the most straightforward explanation around these concepts I have seen.

In case you don’t want to drill down to the link above, following is an excerpt.

I’ve tried answering this question so many times and in so many ways: “What’s the difference between a use case and a user story?”

I know what each is, I know how to describe each; I’ve described each and even how to relate the two. I’ve finally concluded that a user story is to a use case as a gazelle is to a gazebo.

See if you can describe the difference without just enumerating what each is.

As the Mad Hatter asked: “Why is a raven like a writing desk?”

A better answer is A user story is the title of one scenario whereas a use case is the contents of multiple scenarios.

Here is what I just got by using this command.

Microsoft (R) TfsBuild Version 10.0.0.0
for Microsoft Visual Studio v10.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Destroy build record for 258141 permanently? (Yes/No/All) all
Destroying 258141… Done
Destroying 1.6.1.0… Done
Destroying 1.6.2.0… Done
Destroying 1.6.3.0… Done
Destroying 1.6.4.0… Done
Destroying 1.6.5.0… Done
Destroying 1.6.6.0… Done
Destroying 1.6.7.0… Done
Destroying 1.6.8.0… Done
Destroying 1.6.9.0… Done
Destroying 1.6.10.0… Done
Destroying 1.6.11.0… Done
Destroying 1.6.12.0… Done
Destroying 1.6.13.0… Done

… …

Why do I need this? It is because all these builds are accidentally generated due to a cyclic automated check-in when I tried to implement an automated version number increment solution based on this perfect post.

What exactly is the root cause of this cyclic check-in and build? The short answer can be located from here. A little bit more detailed explanation is that, the gated check-in will shelve all the files first and then do a build. Then if all succeed, a final check-in will be made; however, the automated check-in to update the version files, will in turn trigger another gated check-in, and again and again, cyclically.

Then why all these builds failed? Shouldn’t they all succeed? It is because, the automated version increment check-in will use the tf command to check-in the files and for a gated check-in, it will return 1 which means “failure” instead of 0 if it succeeds.

Hence, a check-in triggered the gated check-in build, which in turn triggers another check-in which triggers another gated check-in build, again and again…

The result would be a huge list of incomplete builds that consume a lot of build numbers that you want to get back. In this case, tfsbuild destroy would be your best friend.

Till next time,