Building a URL shortener in 12 lines of code using Cloudflare Workers

Cloudflare Workers Cloudflare Workers is a serverless environment that runs Javascript. Basically, you just write code that handle HTTP requests, similarly to Node.js. The code is deployed globally across the Cloudflare network, which means it’s always running as close as possible to the end user. I was recently playing with Cloudflare Workers to see how it worked, and I realized how incredibly easy it was to make a simple URL shortener with it!

Using multiple JSON serialization settings in ASP.NET Core

My blog has been a bit quiet in the last 18 months or so, because, well, life happened… In that time span I became a father, changed jobs twice, and relocated to Canada with my family, so free time has been scarce. Anyway, I recently ran into a problem that I found worthy of a blog post, and I have a bit of time to write! Heterogenous JSON formats Let’s say we’re building an ASP.

Building a project that target .NET Framework 4.5 in Visual Studio 2022

I maintain a few libraries that still target .NET Framework 4.5 (among others). .NET 4.5 has long been out of support, but I try to keep supporting older frameworks in my libraries as long as it’s not a major inconvenience, because many people maintain old applications that can’t easily be updated to a newer framework. Anyway, until recently, supporting .NET 4.5 wasn’t much of a problem, but today I hit a snag… Before installing VS 2022 on my Surface Pro, I removed VS 2019 and old versions of .

A quick review of C# 10 new language features

.NET 6.0 and C# 10 are just around the corner, so now is a good time to review some of the most interesting new language features! Record structs đŸ“„ Proposal Records were introduced in C# 9 as a simple way to define data types with value equality semantics, for instance: public record Money(decimal Amount, string CurrencyCode); An annoying limitation was that records were always reference types, but in some scenarios it would have been better to use value types.

C# 9 records as strongly-typed ids - Part 5: final bits and conclusion

Created by Wireform from the Noun Project Using C# 9 records as strongly-typed ids
We’re reaching the end of this series on records as strongly-typed ids. Sorry for the long delay since the last post… life happened! So far we’ve covered ASP.NET Core model binding, JSON serialization, and EF Core integration. Almost everything is working, we just need to fix a few more details. Handling database-generated values in EF Core First, I want to address a question asked by @OpsOwns in the comments of the last post:

C# 9 records as strongly-typed ids - Part 4: Entity Framework Core integration

Created by Wireform from the Noun Project Using C# 9 records as strongly-typed ids
So far in this series, I showed how to use C# 9 records to declare strongly-typed ids as easily as this: public record ProductId(int Value) : StronglyTypedId<int>(Value); I also explained how to make them work correctly with ASP.NET Core model binding and JSON serialization. Today, I’ll present another piece of the puzzle: how to make Entity Framework core handle strongly-typed ids correctly. Value conversion for a specific strongly-typed id Out of the box, EF Core doesn’t know anything about our strongly-typed ids.

C# 9 records as strongly-typed ids - Part 3: JSON serialization

Created by Wireform from the Noun Project Using C# 9 records as strongly-typed ids
In the previous post in this series, we noticed that the strongly-typed id was serialized to JSON in an unexpected way: { "id": { "value": 1 }, "name": "Apple", "unitPrice": 0.8 } When you think about it, it’s not really unexpected: the strongly-typed id is a “complex” object, not a primitive type, so it makes sense that it’s serialized as an object. But it’s clearly not what we want… Let’s see how to fix that.

C# 9 records as strongly-typed ids - Part 2: ASP.NET Core route and query parameters

Created by Wireform from the Noun Project Using C# 9 records as strongly-typed ids
Last time, I explained how easy it is to use C# 9 record types as strongly-typed ids: public record ProductId(int Value); But unfortunately, we’re not quite done yet: there are a few issues to fix before our strongly-typed ids are really usable. For instance, ASP.NET Core doesn’t know how to handle them in route parameters or query string parameters. In this post, I’ll show how to address this issue. Model binding of route and query string parameters Let’s say we have an entity like this:

Using C# 9 records as strongly-typed ids

Created by Wireform from the Noun Project Using C# 9 records as strongly-typed ids
Strongly-typed ids Entities typically have integer, GUID or string ids, because those types are supported directly by databases. However, if all your entities have ids of the same type, it becomes pretty easy to mix them up, and use the id of a Product where the id of an Order was expected. This is actually a pretty common source of bugs. public void AddProductToOrder(int orderId, int productId, int count) { .

Automatic factory with Microsoft.Extensions.DependencyInjection and Castle DynamicProxy

Dependency injection: the good and the bad Dependency injection (DI) is a great pattern, which can really help make your code cleaner, more decoupled and more testable. There are many DI libraries, like Autofac, Lamar (StructureMap’s successor), Castle Windsor, etc., but lately I’ve mostly been using the one provided by Microsoft in .NET Core : Microsoft.Extensions.DependencyInjection. It’s not the most full-featured (in fact, it’s pretty bare-bones), but I find it sufficient in most cases.