Async programming has become ubiquitous and the standard tool for making async HTTP requests with C# is
HttpClient from the
System.Net.Http namespace. Examples are aplenty, but good examples are few and far between. Because
IDisposable we are conditioned to new it up in a using statement, make the call and get out as fast as possible.
This is WRONG.
This blog post will pull together advice from the few good resources online that touch on various aspects of why you are using it wrong, and how to use it correctly.
A Basic Example of CRUD with DataGridView in VB.Net being one of my more popular posts, I thought I should provide a C# example. I find people on stackoverflow.com continue to struggle with setting up DataAdapters to perform inserts, updates and deletes, and the use of WinForms is still often the platform used by beginners and students.
So here is a small sample application demonstrating how easy it is. There is an embeded SQLite database so you can immediately run the project without worrying about database setup. The code itself is easily translated for your data provider of choice – where you see “SQLite” just replace it with “SQL” or “OleDB”, or whatever you are using:
SQLiteCommand => becomes => SqlCommand
This time I’ll allow the code to speak for itself, get it here on GitHub.
Are you familiar with the feature of NTFS called Alternate Data Streams? Our typical usage of files is pretty simple. We double click it and it opens. But by default we are only accessing the “default” data stream. We can write to multiple data streams, effectively storing multiple files in a single file. These alternate streams are generally hidden, but we can see them and even write to them. I’ll show you how to do it from the command line and from C#.
If you are coming to this blog post you probably already know what Serilog is and you need to write to a “sink” that is not already provided in the list of Available Sinks. The list is quite long so definitely look closely before developing your own because there is most likely one already built for your needs.
But what if there isn’t? Continue reading
As developers, we are often faced with legacy code bases that were never designed with unit testing in mind. Of course, we now know the value of unit tests and we want to test as much as possible. A good place to start implementing tests in old code is to write tests around each bug and feature. Do not try to refactor the entire pile of rubble, but instead begin with tests around just the code you are adding or changing.
Here I will show you a simple technique to refactor “just enough” to get some tests running without introducing unacceptable risk in your modifications. The examples with be in C#, but the technique applies everywhere.