Hi, I'm Hannes

As a developer, you've probably used to browsing code samples on Stack Overflow and various dev blogs. There's also GitHub, a formidable source of wisdom. You can easily search through all the repositories or narrow it down to your organization by using a couple of modifiers.

In the second half of 2022, GitHub updated their code searching engine and interface. You can use several modifiers and keywords to narrow the search and find what you're after. It even supports regular expressions!

This blog post is meant to be succinct reference for crafting search queries.

Almost every system I've ever worked with had to generate PDF files for reporting, statements etc. Finding a good (and free) library can be tricky, especially in the .NET Core space. Many options out there lack documentation and can have unexpected behaviour. Generating larger PDFs can put a lot of pressure on your system, so moving it into a separate service would make sense.

ASP.NET Core's default template adds RFC7807 Problem Details response to everything that results in 400: Bad Response:

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "traceId": "00-3b3e118eb02dac41bcfc5d7c93509896-daaf187e081ea94e-00",
  "errors": {
    "Foo": ["The Foo field is required."]
  }
}

(note that the field is Pascal cased, whereas JSON is usually camel-cased).

Other response statuses return an empty body. Wouldn't it be nice to receive a nice JSON response, regardless the HTTP status (ie 403, 404, 500 etc)?

Adding OpenApi/Swagger spec generator into an Asp.Net Core app is easy. It even comes preconfigured with the Asp.Net Core 5 template.

Both Swashbuckle and NSwag offer quite easy extension points to further customize the spec generation. For example you can add 401 and 403 response types automatically based on the [Authorize] attribute. This saves you from manually decorating all the methods.

Access to script at 'https://cf.yourdomain.com/script.js' from origin 'https://yourdomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Looks familiar? Read on!

AWS CloudFront is an excellent CDN service when hosting your static assets. If you're referencing your scripts with the crossorigin="anonymous" turned on, then the browser sends through an additional header: Origin: https://yourdomain.com. Now, the response has to include the header Access-Control-Allow-Origin, or otherwise you'll get the error above.

Provisioning local infrastructure can be a bit cumbersome, at least during the initial setup. Docker to the rescue! If you haven't used Docker yet then get on it ASAP!

With a simple command, you can provision (and seed) different resources like databases, messaging queues and other services. In this article, I'm going to show you how to create a few simple scripts to get you going with Postgres AND seed some data.

If you're using your own NuGet packages or consuming 3rd party ones, then you've probably faced the pain of stepping (or rather not stepping) through it's source code.

Forget the symbol and source servers, there's a new and friendlier kid on the block: Source Link. Formerly you had to upload your symbol (PDB) and source files to different locations and use several switches during the build. Even that didn't guarantee you success, downloading source files often failed miserably.

Source Link is here to ease your pain, it is a developer productivity feature that allows unique information about an assembly's original source code to be embedded in its PDB during compilation.

While making this blog I needed a quick way to log failed requests for later analysis. If you've developed ASP.NET applications in the past, then you've probably used good old ELMAH package, which automagically logs your unsuccessful requests.

Good news, this is easily achievable in ASP.NET Core via something called middleware. If you're not familiar with middleware then I suggest you go and take a few minutes with the article.

Opening and building large Visual Studio solutions is a pain. A good way to put less stress on your rig is to start moving rarely changing parts of your code into NuGet packages. NuGet has been around already since 2010, tools are mature and battletested. NuGetizing some of your system makes parts of your code always prebuilt and tested (you are using tests right?). Offloading some of the building and tests will make your overall CI (Continuous Integration) process faster as well.