In my previous blog post about LocalStack S3 setup I’ve included a hardcoded delay of 5 seconds before actually calling AWS SDK. This gives enough time when waiting LocalStack to start and be ready to accept incoming requests. However, what is actually enough?
If you use AWS S3 and don’t want to use the actual bucket for one or another reason for your local development, you’ve probably come across LocalStack S3 mock for this. Especially, if you are running your apps or integration tests in Docker.
A quick example to illustrate an implementation of a custom Unauthorized response body in ASP.NET Core 2.0. The implementation is based on the AuthorizeFilter from Microsoft MVC framework.
I was setting up Amazon SQS client locally, and received No RegionEndpoint or ServiceURL configured exception. My goal was to load all AWS config values from environment variables together with a temporary session token, however I will go trough config file option as well. Apparently region value was not picked up by the Amazon SQS client.
This blog post shows a quick example of implementing custom authentication in .NET Core 2.0 to secure your Web API. And in most cases you do want to secure your Web APIs, even though they were internal (micro)services only. If you don’t have a proper Identity provider e. g. Identity Server in place, and just need a quick solution, then a simple option is to validate Authorization header against a hardcoded value.
From all different solutions for various problems I’ve implemented in the past I wanted to create a simple web application that I could get back to for reference any time, and this would be a fully working KnockoutJS web application. The idea was to implement a simple client contacts management application using .NET Core 1.1, Entity Framework Core 1.1, KnockoutJS, and MSTest + Jasmine for unit testing.
Recently I’ve been working on several small .NET Core web apps and was looking for two things. Firstly, a way to access Session in a data service directly, and not just by passing HttpContext reference down from controller. And secondly, log any unhandled exceptions that occur in the application. And the answer to both questions was IHttpContextAccessor interface!
I’ve decided to write this blog post when I came across an issue with Swashbuckle trying to validate JSON file in Swagger and was failing since Swagger’s online validator was trying to fetch JSON file from an development server which is not accessible from external networks.
Different developers have different coding styles, however when you work as a team you want to make sure everyone can quickly pick up any part of code and could get their head around in no time. For this reason, it’s great when code has unified style. This can be done manually (not recommended :)) or by using code analyzers in Visual Studio. Default set of rules check for the most common issues, however do not keep the coding style itself unified. Therefore, such tools like StyleCop Analyzers become really handy in such cases. Continue reading .NET Core projects with StyleCop Analyzers
In my previous blog post I’ve implemented a very simple application to illustrate dependency injection (DI) using Ninject. While Ninject is flexible and powerful, you might want to try different dependency injection libraries before you make your final decision on what to use. And this time I wanted to look into the latest dependency injection library which comes as a default option for MVC 6 and .NET Core – Microsoft Dependency Injection. And yes, the name is very easy to remember :)