Every developer knows that unit testing improves the quality of the code. We also profit from static code analysis and use tools such as SonarQube in our build pipelines. Yet, I still find that many developers are not aware of a much older way of checking the validity of the code: assertions. In this post, I will present you the benefits of using assertions, as well as some configuration tips for .NET applications. We will also learn how .NET and Windows support them.
I recently spent some time analyzing OutputDebugString method. For my another experiment I needed a version of OutputDebugString which depends only on Native API. While implementing it, I discovered few interesting facts about OutputDebugString that maybe will interest you too. The title mentions System.Diagnostics.Trace. It is because the default trace configuration in .NET sends trace messages to an instance of the DefaultTraceListener class, which uses OutputDebugString. And if you do not remove it explicitly from the trace listener collection, your logs will always go through it. You will later see why sometimes it might not be a good idea.
I recently had an interesting issue in one of our applications. The SMS router, responsible for sending and receiving SMSes, hanged – there was no CPU usage and we haven’t observed any activity in the application logs. I collected a full memory dump and restarted the service, which seemed to come back to its normal state. Curious what happened I opened the dump in WinDbg, loaded PDE and SOS and started an investigation
In one of our applications I recently observed timeouts in code performing HTTP requests to the REST service. While investigating this issue I discovered few interesting facts about System.Net namespace and would like to share them with you. We were using objects of type System.Net.HttpWebRequest in our code, but some of the information presented in this post will also apply to the newer System.Net.HttpClient implementation.
Diagnosing Windows Services might sometimes be cumbersome – especially when errors occur during the service start. In this two-parts series I am going to show you different ways how to handle such problems in production. In the first part we will focus on “exceptions discovery” techniques which very often are enough to figure out why our service is not working. In the second part we will setup a debugging environment and attach a debugger to our service. Let’s start then.
I’m a great fan of the Essential.Diagnostics and this post will be again committed to this library. In our company we use MS SQL Server as our main database server and an instance of MySql to store logs from applications. If you are using System.Diagnostics tracing you probably lack more advanced trace listeners (like the ones provided by log4net). A remedy for this problem might be the aforementioned Essential.Diagnostics library. In this short post I will show you how to configure the
SqlDatabaseTraceListener to work with MySql database.
I don’t need to stress how tracing (logging) is important in any application. Without logs we are often unable to diagnose the cause of the failure. Logs also help us track application behavior and usage over time. Fortunately there are numerous libraries (including .NET framework itself) that can help us create meaningful logs. In this post I would like to show you how to, using System.Diagnostics classes, nicely group application traces by activities to which they correspond.