Posts

Building Microservices with Asp.Net WebAPI, Owin, Ninject, NHibernate, and Azure -- Part 2: Error Responses and Exception

Last time  we looked at setting up a microservice based on WebAPI with dependency injection an persistance. In this article, we’ll look at global exception handling and error responses. The Error Response We return standard error message formats for 500 errors. In WebAPI, Microsoft uses  HttpError  internally within the framework. For consistency, we do the same. That way, whether the error was generated in the pipeline, or by our business logic, the message is the same. Under the hood, HttpError inherits  Dictionary . You can add custom key/value pairs for anything you’d like to return. The response the looks something like… { "message" : "An error has occurred" , "exceptionMessage" : "Object not set to an instance of an object." } The dictionary keys to look up standard error information are available on the  HttpErrorKeys  type. Using it, we can generate a  IHttpActionResult  to return… public class Except...

C# DateTime, DateTimeOffset and the Cloud

One thing to remember,  System.DateTime  has no knowledge of timezone. It’s only aware that the date and time represents UTC or the local timezone of the machine on which the code is running. In the cloud, by default (and it’s best to keep it that way), the “server’s” timezone is set to UTC. So what? Well… The serializers do some magic that can yield undesired results depending on your situation. Take the following… DateTime today = DateTime . Today ; Seems harmless. If you inspect this instance further, you’ll see that the Kind is set to  DateTimeKind.Local . So, when working with the instance, it will behave in the timezone of the machine. If you serialize it on your laptop, and your laptop’s timezone is set to “Easter Standard Time” (America/New York for you Linux/Mac folks)… string json = JsonConvert . SerializeObject ( today ); Console . WriteLine ( json ); …you get… 2018-02-23T00:00:00-05:00 Notice the timezone offset. If  Dat...

Adding New Microsoft Extensions to Legacy WCF and ASMX Web Services

I was asked by several people recently: Can I use dependency injection with my legacy WCF and ASMX web services? Microsoft has some new stuff they released with core–specifically, a new configuration system, caching, and logging providers. Can I use them in my legacy WCF and ASMX web services? The answer to both is yes you can! In fact, I recommend it! To illustrate this, we’ll take a look at taking a sample application that has a WCF service and a ASMX service and we’ll: Add dependency injection using Ninject. Add the new Configuration provider from the new  Microsoft.Extensions.Configuration  packages. Add caching functionality using Microsoft’s new  Microsoft.Extensions.Caching  packages. Use the new logging providers from  Microsoft.Extensions.Logging  packages. Dependency Injection We use Ninject, but you can just as easily use AutoFac or SimpleInjector as they also have packaged integrations for WCF. You can use other containers, bu...