Tip of the day #2: Problem with your WCF hosting? Probably an ABC matter!

Today I faced a nice little issue. It wasn’t something mindblasting and the solution wasn’t somehow innovative, but rather a 5-minute issue to resolve (If I had said the ABC out loud first). Instead it was a 30 minutes work. I was asked to make a new WCF web service to provide some functionality for our business case. Some structural background on the project I was working on: It is a Silverlight application, with client-side data management UI, a server-side with (web) services supporting our business logic and a LOT of (disconnected) business objects flying around like crazy, between the web application and the client. This orchestration was ment to be disturbed until today, by me, creating two more WSs’, the first for a certain operation taking place server-side and a second, stand alone, little web service doing some stuff at a third tier in another machine (which is used by the former). I spent more than 30 minutes in the morning (before coffee) asking myself what have I done wrong, and the client (first WS) didn’t recognize my configuration elements. The same dialog between the debbuger again and again, under various tweakings…

-Visual Studio says: Sorry, I cannot find default endpoint element that references contract IService******* in the ServiceModel client configuration section.

-Aggelos says: I am going by the book, what is wrong?

-Visual Studio says: Hahahaha, lolz, think again, you happy programer!

What was going wrong? Go back to the beginning, and remember. All the server functionality is supported by a certain web application with it’s own web config. My web service (the client one) had it’s own project under a WCF service library project. The WCF was hosted by the Web Application so… yeah that’s the answer. The configuration resides in web.config of course, even if the WCF (library) is somewhere else…

ABC stands for Address, Binding, Contract…missing one of them, breaks all of them… what about missing all of them? :P:P:P:P:P

Tip of the day #1: Love and take care of your MSDTC connectivity

You have a nice day, but something is missing. Your first debug tryout, after some hours of refactoring and new feature coding. After the successful built, you get your first exception (the usual handled exception that is logging something). Usually the exception is self-explained, it gives you the right information and with a little bit of help from the call stack you pin-point the failure. So, let’s see the code…xmmmm…the error is somewhere on my tested-and-working-perfect-until-now part of my module… The exception is accompanied with a transaction lock. But why? You keep unlocking the database via the Activity Monitor of SQL Management Studio, you retest the code, step by step, but you can’t pinpoint the the problem. Why my thread does that to me, what have I done? Why does it lock my data during the business object save?

As a matter of fact, during the day, I have done 3 things in general:

• I have been coding in a region, not even executed when the lockout occurs.
• I have participated in updating the db server (another physical machine)
• I have deployed several updates to my system, including SP3, during the previous night.

So after an hour of pair-debugging, my colleague concludes that there isn’t anything wrong with the code itself, so the first bullet is gone. The problem occurs when data switches transaction mode during persistence, to distributed transaction, so we have two machines, with “maybe” recently-damaged MSDTC settings. Either my machine or the db server. By restarting after checking the settings at the db server, the problem still exists. So, the 2nd bullet is gone too. What is wrong with my pc after all?

And then, after a couple of hours I hear a magic voice screaming to me: OMG!!! Check Immediately your firewall! And there it was, the filthy, stupid (not even a) bug… that had jumped from the code and settled somewhere else. The newly-during-the-night-updated system, had restored settings and rules at firewall, ending the communication of my Microsoft Distributed Transaction Coordinator with the outer world…

Tragic….but still funny :P

Tip of the day #0: Admit your SLCM’s

How many of you, have experienced an embarrassing –at yourself- code bug situation? You know, that you were better than this one, but you don’t want to admit it. You go home at night, thinking about it. You dream of it, laughing in your face…it’s laugh jumps out, through the code blocks, haunting your existence… it isn’t a logical error in communication of the wireless sensor network you recently engineered, it is a bug, residing in your configuration file… it isn’t an algorithmic fault, in your genetic algorithm … your algorithm doesn’t execute well because of the non-printable character in this f%@#$@#$ string (or char* I still love you). Finally, your business object doesn’t lazy load… -why god…pls give me strength –[god]My child take some rest, you have a buggy old version of your ORMapper, go get some sleep.

Admit your stupid little code mistakes. They are part of your professionalism. I will post some worth-mentioning situations just for fun (and non profit at all - :P:P:P).