Today I ran into a stupid problem while working on a WCF web service. The web service has to return a special response object which includes some further complex data objects. But after assigning these objects to the response object, my web service stopped working with an unsignificant error:
System.ServiceModel.CommunicationException: The underlying connection was closed: The connection was closed unexpectedly. [..]
So what to do now? I wasn’t able to find a helpfull hint where the error occurs or what the error releases. My client side stack trace was unusable for debugging, so I had to find a way for debugging on the server side and found a quite good solution: System.Diagnostics.XmlWriterTraceListener.
To activate the trace listener on server side just append the following lines to your web.config:
If done, after a request you will find the file “Trace.svclog” server side which contains all information you need for debugging. You can open it with “Microsoft Service Trace Viewer” which simplifies the evaluation of service behaviour. So if you get an unsignificant error on client side be sure to find more information in trace log on server side!
P.S.: By the way, my error was a serialization error and now it works :)
This is the video of the fourth day our work week. It is a little bit shorter than the last two videos. Yesterday my machine broke down and we forgot to start the webcam again.
This is the video of the third day of our work week. This time it has even sound. The sound is from Big Buck Bunny. (c) copyright Blender Foundation | www.bigbuckbunny.org
This is the video of the second day of our work week. This time it has even sound. The sound is from Big Buck Bunny. (c) copyright Blender Foundation | www.bigbuckbunny.org
I nearly spend the whole day to make and to upload our first video. But here it is. For every day we will post one video. At the end of our work week you will get the full movie of the whole week.
This is the mission of our team for the next days: building one Facebook app – SnipClip – in one week – or at least a pre-alpha-version. We invite you to participate in this process by joining our Facebook party. It’s fun – take a look:
You’ll find more pictures and videos of our Facebook app and us on Facebook.
Btw.: the timing is perfect. Facebook just announced that are changing the profiles and adding new features this week! It’s gonna be a tough work week – launching a new app during a relaunch! Have a good time!
Just like with golf, technology is as much about ensuring that your bad hits are recoverable as it is ensuring that you make great ones. We’re all going to have failures in our careers but avoiding the really big pitfalls will help you keep your company on the right growth path. Here are 10 common mistakes we at AKF Consulting see made during platform development — and the ones we believe are the most important to avoid.
If companies would adopt test-driven development consequently, they would save time – but also money? No, not necessarily. Developers make bugs and so should also test for bugs. Test-driven development detects bugs early in the development process, but requires an significant time investment. Support staffer fill bug reports and so help locating the bug.
Support staffer get low incomes, because they needn’t a diploma or any other qualification. Developers, on the other side, are rare, highly qualified and so get an high income. Costs are determined by the wage rate multiplied with the time needed for a certain job. Bug detection can be done by developers as well as by support staffers. So it seems to be better to pay for support than for development. Sometimes support is even another source of income! Isn’t it great? No, of course, it is not, because those people forget the customer satisfaction, which weights in the long run more than the cost reduction.
