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.