Category: csharp

My experience working my way through the Clean Code book and videos has gotten me interested in refactoring some of my old code. I have a large API project that I maintain at work, and it’s gotten a little out of hand over the last few years. In particular, there’s one class that got so large that I broke it up into multiple partial class files some time ago. Overall, it would have been around 5000 lines of code if I hadn’t broken it up. Of course, partial class files don’t really change anything; it’s still one big class, technically.

So I started looking for ways to break it down into actual separate classes. What I wound up doing was to leave stuff that was needed across all the code in the old class, then moving all the specific stuff from the partial classes into new “child” classes. I created a new base class for these child classes, then added code to the original (now “parent”) class to contain all of the children as singletons, instantiated as needed.

The code to do that looked a lot like the code in this Stack Overflow question. That was fine, but once I got all that done and working, I started looking around for ways to streamline or simplify the declarations. I tried out a few things, and decided on using the Lazy<T> class. I’m sure I must have stumbled across it before, but I’d forgotten about it and had never actually used it. It took me a little while to figure out exactly how I should use it, in my particular use case. I don’t have anything super-interesting to say about that, but I thought I’d just post a few links that I found helpful:

• Lazy Initialization – from the MS docs.
• Getting Lazy in C# – from Matt Eland.
• Implementing the Singleton Pattern in C# – from Jon Skeet’s C# In Depth.

Overall, I think the code is a little better for having been refactored this way, though I’m still not quite satisfied that I’ve cleaned things up as much as I should.

I had a little task today at work, where I needed to replace the way I created a JSON object that was being returned from an API. Long story, but the challenge at the end was to make sure I didn’t screw it up, so I wanted an easy way to compare the “before” and “after” JSON. Now, I was adding a feature here, so the before and after were going to be different, but I wanted to have an easy way to check that they were different only where I expected them to be, and there weren’t any unexpected side-effects.

This let me down a rabbit hole, looking at things like this ObjectsComparer package on GitHub. I also stumbled across this JSON extension for FluentAssertions. In the end, I just wrote a script in LINQPad to dump the before & after JSON to disk, then compared it with Beyond Compare. I keep thinking that I need to put together a better testing framework for my API, so I can better automate this kind of stuff.

I don’t have a unit test project for this API, or any other really structured tests. I have a test client that can run a suite of “safe” tests that don’t alter data, and checks a few things on the results. But it’s not a very complete test set. And I have another client that runs a test cycle that does alter data, and hence needs to be run carefully, and can’t be run too frequently. (And that one isn’t very complete or thorough either.) And I have some LINQPad tests that I run mostly as smoke tests.

I’m currently working my way through the TDD section of the Clean Code series that I’ve been watching/reading. I’ve always liked the idea of TDD, but I’ve rarely worked on a system where it seemed practical. (I’m not saying that it’s not practical, just that I haven’t figured out how to effectively apply it to any of my typical work.) Regardless of TDD, I ought to be able to put together some better and more automated tests for some of my work.

I haven’t written a programming-related post in a while. I just had to rewrite some code that used ADAL to use MSAL, so I thought I’d write up a short post on that.

There’s a bunch of documentation around this on the Microsoft web site, but for the simple case I was interested in, it took some effort to track down.

Here are links to a couple of general articles:

• Migrate applications to the Microsoft Authentication Library (MSAL)
• Differences between ADAL.NET and MSAL.NET apps

What I needed was to rewrite a small block of code that calls a web API from a console app, with no user intervention. I have an Azure app registration set up to help with that, with a client ID and secret, and all that stuff. I have some links on how to set that up somewhere, but I’ll skip that for now.

The actual code I needed was something like the code here (to initialize MSAL) and here (to get a token). After I get the token, I just add it as a bearer token to the header for the request.

Here’s a bit of “before” and “after” code:

// before:
using Microsoft.IdentityModel.Clients.ActiveDirectory;

// get the parameters from a config file, or somewhere...
string clientId = ConfigurationManager.AppSettings["ClientId"];
string clientSecret = ConfigurationManager.AppSettings["ClientSecret"];
string authority = ConfigurationManager.AppSettings["Authority"];
string svcResourceId = ConfigurationManager.AppSettings["ServiceResourceId"];

AuthenticationContext authContext = null;
ClientCredential clientCredential = null;

authContext = new AuthenticationContext(authority);
clientCredential = new ClientCredential(clientId, clientSecret);
AuthenticationResult result = null;
try
{
	result = await authContext.AcquireTokenAsync(svcResourceId, clientCredential);
}
catch (AdalException ex)
{
	Console.WriteLine(String.Format(
		"An error occurred while acquiring a token\nTime: {0}\nError: {1}\n",
		DateTime.Now.ToString(), ex.ToString()));
	return;
}
//Console.WriteLine("Access Token: {0}", result.AccessToken);

client = new HttpClient();
client.BaseAddress = new Uri(BaseAddr);
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
// Add the access token to the authorization header of the request.
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);

// after: 
using Microsoft.Identity.Client;

IConfidentialClientApplication app = ConfidentialClientApplicationBuilder.Create(clientId)
	.WithClientSecret(clientSecret)
	.WithAuthority(authority)
	.Build();

AuthenticationResult authResult = null;
try
{
	List<String> scopes = new List<String>() { svcResourceId + "/.default" };
	authResult = await app.AcquireTokenForClient(scopes).ExecuteAsync();
	//string accessToken = authResult.AccessToken;
	//Console.WriteLine($"Access Token: {accessToken}");
}
catch (Exception ex)
{
	Console.WriteLine($"MSAL Error: {ex.Message}");
}

I’m not sure if anyone other than me will ever find this useful, but here it is, just in case.

Here’s another blog post about the program I’m currently working on at my job. This is the same program I blogged about yesterday and a couple of weeks ago.

Today, I was trying to fix a performance issue. The app originally ran really fast. It just had to make a few API calls, filter and combine some data, then spit it back out in JSON format. It took less than a minute to run. But then, I was asked to add a new data element to one of the files. An element that I could only get by calling a new web service method repeatedly, once per order, for about 7000 orders. It shouldn’t be an expensive call, but the end result was that my 1 minute runtime was now up to 10 minutes.

The first thing I tried doing was adding some concurrency to those 7000 new API calls. I did that using the first technique described in this article, implementing a ConcurrentQueue. I wasn’t really optimistic that it would help much, but I thought it was worth a try. It didn’t really help at all. The program still took about 10 minutes to run. So I undid that change.

The next thing I did was to look and see if I was repeating any of the API calls. While I was processing 7000 records, there were some cases where the same sales order number was found on multiple records, so I was making extra unnecessary API calls. So I implemented a simple cache with a dictionary, saving the API call results and pulling them from cache when possible. That didn’t help much either. About 90% of the calls were still necessary, so I only got down from 10 minutes to 9 minutes. But that was at least worth doing, so I left that code in place.

Then, finally, it occurred to me to look at how I was calling the API. This new API call was part of the WCF SOAP service that I’ve mentioned previously. Well, the way I wrote my wrapper code for the API, I was creating a new call context and service client for every call. I didn’t think that would be a huge issue, but I went ahead and refactored things so all the calls used the same call context and client. Well, that got the execution time back down to one minute. So really all of that extra time was spent in whatever overhead there is in spinning up the WCF client object (and I guess tearing it down when it goes out of scope).

That was really unexpected. I hadn’t thought about it much, but I assumed the code behind the instantiation of the service client was just setting up a structure in memory. I guess that maybe it’s also establishing communication with the server? Theoretically, I could dig into it, but I don’t really have the time for that.

The moral of this story is that, when performance tuning, some of the stuff that you think will help, won’t, and some of the stuff that seems dubious, might actually make a huge difference!

I haven’t written many programming-related posts lately. A few months ago, I was doing a bunch of research into stuff related to async and await in C#, and made some notes that I intended to turn into a blog post. Three months later, they’re all still in my Evernote “inbox” notebook. Well, maybe it’s time to finally get around to that post. Of course, now, I barely remember what I was doing back then, so this post is mostly going to be a bunch of links to resources. Maybe it’ll come in handy the next time I need to solve an async/await problem.

When I was trying to figure this stuff out, I found myself reading a lot of stuff by Stephen Cleary. His blog has a lot of useful posts about async programming. His async OOP series is interesting. Those posts led me to look into his Concurrency in C# Cookbook. His MSDN article from 2015 on Brownfield Async Development was relevant to my project too.

Now I’m starting to remember what I was going to write about… It was going to be a post about the challenges of retrofitting async calls into a Web API project that didn’t initially use the async/await patterns. I had to do this due to some changes in another API that I was calling. Those changes aren’t worth getting into here, but I found that async tends to become an “all or nothing” proposition. I was initially running up against some blocking problems, which led me to Stack Overflow, which then led me to Stephen Cleary’s blog post titled Don’t Block on Async Code.

Later, I started hitting some problems that required me to put some effort into limiting concurrency on certain calls, which led me to this MSDN post and this post from Mark Heath. I wound up doing something with SemaphoreSlim. (At least that’s what I think I did…)

Anyway, my project is working fine now, in production, and everyone seems reasonably happy with it, so I guess I got all this stuff right in the end.