I like this statement: The 100% coverage practice is costly only when it forces substandard code to be well designed.

jack4itLeave a comment

And it is from a post of Patrick Smacchia on simple-talk.

Patrick wrote an essay about writing unit testing code in c#, in which I personally found a lot of good points that I could not agree more. For example:

  • Not all classes need to be 100% covered by tests or even covered at all.
  • The 100% coverage practice is costly only when it forces substandard code to be well designed.

And especially for the second one, I think it is inspirational and encouraging. I faced situations from time to time that for some certain pieces of codes/logic, it was difficult to write a comprehensive test suite to cover all the branches. Honestly, most of time when I faced this, I will choose to leave the coverage not to 100% and accept the fact. But after reading this, from now on, I will try my best to achieve the 100% coverage by not only writing comprehensive test cases, but also refactoring the “difficult” logic to the best designed, intuitive, and enjoyable to read codes.

I like this statement: The 100% coverage practice is costly only when it forces substandard code to be well designed.

Be careful when you use both Windows Azure Diagnostics and auto cspack build

jack4it, , Leave a comment

Recently, one application I work on encountered an interesting issue. We have configured WAD to forward the Windows event logs to a storage account. And it used to work very well. However, after a recent new deployment, all Windows event logs on the web role machines stopped to forward. Logs on worker role machines are still transferred, though.

We re-examined all the configurations, Entry Point codes to start WAD monitor, storage account connection string. Everything looks fine because we didn’t change them for the latest release.

Then what the heck happened to the web role machines? The application works fine, logging works fine. Only WAD doesn’t work? And I didn’t notice any WAD related errors.

I searched the Internet and came to this post which helped resolve the problem. I actually use another approach to resolve this particular issue. But the essential part of the approaches are the same.

So, the issue is due to we changed the auto build approach for the latest release. Originally prior to the new build method, we simply use the Publish target of Windows Azure MS Build extensions. However, for the latest release, since we enabled CodeSign to all our assemblies, we need to repack the Azure package to include the CodeSign-ed assemblies. And the original Publish target is not very convenient to be integrated into the TFS build system.

We updated the TFS build template to include a new activity which simply invoke the cspack to repack the Azure deployment package. And in the arguments of the cspack command, we missed the EntryPoint part of the /role parameter for the web role of our application.

After simply changing the TFS build template, now the new package restarts to initialize WAD and all the logs on the web role machines come to storage as expected.

Hope this helps,

-Jack

Be careful when you use both Windows Azure Diagnostics and auto cspack build

build agent cannot be removed due to problematic reserved build

jack4itLeave a comment

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.

build agent cannot be removed due to problematic reserved build

have you ever really understood how Reliable Sessions works?

jack4itLeave a comment

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.

have you ever really understood how Reliable Sessions works?

/debug, /optimize

jack4itLeave a comment

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)]
/debug, /optimize

scenario, user story, use case

jack4itLeave a comment

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.

Gazelle on gazebo.png
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.

scenario, user story, use case

tfsbuild destroy is your friend

jack4itLeave a comment

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,

tfsbuild destroy is your friend

Database.ExecuteSqlCommand

jack4it, 2 Comments

Database.ExecuteSqlCommand is very useful when leveraging Entity Framework 4.1/4.2 Code First model to do the data access or object relational mapping. To make sure your code is bullet proof for SQL injection attacks, you must use the parameterized SQL script when calling this method. Following is an example for this purpose.

context.Database.ExecuteSqlCommand(“delete MasterSmsCampaignCertificateInfo where MasterSmsCampaignGuid = @p0 and CertificateId = @p1“,
    TheCampaignGuid,
    certInfo.CertificateId);

Database.ExecuteSqlCommand