Category: programming

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

Since I’d been away from .NET for a while, I hadn’t really had an opportunity to dig into the new (to me) async stuff. Here’s a good article from 2016 that delves into it.

Six Essential Tips for Async on Channel 9 is also really good.

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

Json.NET has been around for a long time, since 2006; I remember using it at my previous job. Since then, it’s become the default Json serializer/deserializer for .NET. I think there’s a way to deal with Json in .NET without it, but I can’t imagine why you’d do that. I don’t have much to say about Json.NET, just that it works great and I’m glad it exists.

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

I can’t emphasize enough how useful Fiddler is for testing a REST API. My project is essentially a REST API calling another REST API, so Fiddler is doubly-useful for me. I can test my own API, and I can see what the external API is returning to me. I even went as far as buying Eric Lawrence’s Fiddler book. I’ve read about half the book so far, and I’ve learned a lot from it, both about Fiddler, and about HTTP in general.

I used to use curl for testing REST APIs, but Fiddler’s composer tab is much nicer. (Having said that, I’m still glad to hear that curl is going to be available in the standard Windows 10 install soon.)

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

I don’t actually have much to say here. I set up the standard unit testing project that’s built into the VS 2017 Web API project template, and went through the motions of setting up some tests for one of my controllers. (There’s documentation on that here.) But I didn’t get very far, since I don’t really have an effective mocking strategy for the external API that my API is calling out to.

I started looking at Moq, but didn’t get too far. So maybe this is something for the next project, or version 2 of this project.

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

If you’re going to create a REST API, it’s important to document it. For a project at my last job, I created a whole Drupal site to document our REST API. I wrote all the documentation from scratch! With the standard Web API template in VS 2017, you get documentation for free. (Well, almost free.) Here’s an article explaining how to set that up.

I also decided to create Swagger docs with a library called Swashbuckle. Swagger is pretty cool, and seems to be very popular right now. (If you want to use Swagger with ASP.NET Core, here’s a good post on that.)

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

On past .NET projects, I’ve generally used log4net to handle logging. I like the rolling file appender and generally use that. For this project, I decided to look at what else was out there. I found Serilog, and decided to give that a try. It worked out really well. I think I’ve found my new default .NET logging library. It has a rolling file sink similar to log4net. And it’s very flexible and configurable.

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

One of the first things I wanted to figure out on this project was how to make use of Dependency Injection / Inversion of Control. I’d read about it before, but never really quite figured it out. The original source for the DI/IoC concept is from a Martin Fowler blog post from 2004.

I evaluated a few options for my project, and settled on using Autofac, which is a well-documented IoC container that works well with Web API. This video from Channel 9 helped me figure out how to get started with Autofac and DI in general.

I also considered Ninject and StructureMap. I don’t have much to say about those, since I didn’t wind up using them.

The end result of all this is that I think I finally have a decent working understanding of DI/IoC.

This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.

For the .NET project that I’ve been working on recently, I’ve had to play a bit of “catch-up,” since I haven’t been doing too much .NET/C# development recently. My part of the project was to create a middleware API (for lack of a better term) that would provide a simplified internal interface to a more complicated external REST API. I decided to make my API a REST API also, since that’s pretty much the standard at this point. I’d done a lot of work with SOAP APIs in the past. And I’d created a REST API in .NET at least once before, using WCF. Back then, I probably started out by reading something like this article from 2008.

The way to do this stuff now is Web API. The most up-to-date way would be to do this in .NET Core. I couldn’t do that, for reasons that are kind of complicated and not worth going into. (Actually, at some point, I figured out that I probably could do it with .NET Core, but by that point I was too far along to go back.)

I used a few resources to get started. I watched a couple of video courses on Pluralsight: Jon Flanders’ Intro to ASP.NET Web API and Shawn Wildermuth’s Implementing an API in ASP.NET Web API. I also read the book ASP.NET MVC 4 In Action. This was somewhat out of date (last revised in 2012), but was still useful.

So let’s call that my day one post: I started a Web API project, using VS 2017, and the standard .NET Framework.

Back around Thanksgiving, I got interested in stuff like the F# Advent Calendar, the C# Advent Calendar, and Advent of Code. I’ve been working on a pretty cool .NET project at work recently, and I got the idea that maybe I’d do a series of blog posts about various tools and techniques that I’d come across while working on this project. I haven’t written a lot of programming-related blog posts lately, so I though this would be a fun way to get some programming content back on the blog.

I originally thought I’d try to follow the Advent Calendar model, and do one post a day for 25 days, starting on 12/1. Then, when I didn’t get around to starting that, I thought maybe I’d do a Twelve Days of Christmas thing, and do twelve posts from 12/13-24. Now that it’s past Christmas, I’ve decided to just do twelve posts and skip the whole Advent/Christmas connection. I’ll just call it “12 Days of .NET”.

I’m not going to be too ambitious about this. Most of the posts will probably be short, and I’m not going to post a lot of code. Mostly just links to stuff that I found useful. I’ve got most of the posts written already (at least in rough form), so I’m going to set them up in advance to auto-post every day for the next twelve days.