Category: programming

Twelve Days of .NET: Day 11: HttpClient

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.

The standard way to call a REST API in .NET is to use HttpClient. I don’t think HttpClient existed yet when I first needed to interact with REST web services, several years ago. I remember using something called RestSharp, which, I now see, still exists and appears to still be actively maintained, with some fairly recent commits. (Including several on Christmas Eve!)

Here’s a good overview article on how to use HttpClient. And here’s an important blog post on how NOT to use it.

And here’s another interesting blog post, that goes a lot deeper into disposal and finalization with regard to HttpClient. (I have to admin that I’ve only skimmed this post. But I should really read it.)

One surprising thing I discovered while working on my current project is that HttpClient doesn’t have a PatchAsync method. The workaround is pretty easy, and can be found in that linked GitHub issue, and in a number of StackOverflow answers.

Twelve Days of .NET: Day 10: Pluralsight

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’ve used Pluralsight a lot over the last few months, to try and learn some of the new stuff I needed to know to get my current project done. I went ahead and renewed my membership recently, so I’m set through 2018. We’ll see how much use I get out of it in 2018.

Here are a few courses I finished recently:

That last one didn’t really have anything to do with my current project, since I used VS 2017 and not VS Code, but I was thinking about using VS Code for it, initially. I like VS Code as a tool, but, given a choice, I’ll stick with the full VS 2017.

And I’ve started this course: Web API v2 Security by Dominick Baier

I actually have a lot to learn about security and authentication/authorization for Web API, but it’s not that important for my current project, since it will only be used internally.

I have a lot of other videos bookmarked in Pluralsight. I’ll probably get around to watching a few of them, but I haven’t really been spending much time on that lately. At work, I’ve been busy programming, and at home, I’ve been busy watching Netflix and reading comic books.

Twelve Days of .NET: Day 9: Git and TFS

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.

At work, we have a TFS 2012 server for version control. We’re pretty much stuck with that, because the TFS integration in AX 2012 can be a little finicky, and we don’t have a really compelling reason to upgrade anyway. I know that recent versions of TFS (starting with 2013 maybe?) support hosting Git repos, but I think I’d be stuck with TFVC anyway, for a variety of reasons.

For my current .NET project, for which I’m using VS 2017, I started out with a local Git repo, intending to kill it and switch to TFVC when it was ready to go into test. I’m liking Git enough, though, that I’ve stuck with it, and have come up with a somewhat kludgey workflow, where I use Beyond Compare to periodically copy changed code files from my “work” project to a copy of the project that’s bound to TFS. So I code and test locally in the Git version of the project, committing often. Then, when I’m ready to deploy to my test server I follow a workflow where I copy to the TFS project, check my changes into TFS, then deploy to our test IIS server. As I said, it’s a bit of a kludge, but it works for me.

I thought about trying to use git-tfs, but I didn’t want to go down any rabbit holes so I stuck with the simple (but ugly) solution. And I’d love it if we could just switch to VSTS, but I don’t think that’s going to happen either.

Twelve Days of .NET: Day 8: Async

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.

Twelve Days of .NET: Day 7: Json.NET

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.

Twelve Days of .NET: Day 6: Fiddler

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.)

Twelve Days of .NET: Day 5: Unit Testing

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.

Twelve Days of .NET: Day 4: Web API documentation

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.)

Twelve Days of .NET: Day 3: Logging

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.

Twelve Days of .NET: Day 2: Dependency Injection / 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.

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.