Showing posts from August, 2018

Continuously deploy infrastructure with GitLab Pipeline

Continuously deploy infrastructure with Gitlab Pipeline Few weeks ago we saw how we could Setup continious integration and deployment to deploy an application using Gitlab Pipeline . We configured a service with systemd and had an ASP NET Core application automatically deployed when code was pushed to the repository. This automation allows us to reduce interaction with the server and reducing the manual work. The “infrastructure” configurations like systemd service files and nginx site files must also be created or edited on the server therefore it makes sense to also have them automatically deployed. On top of that, it makes even more sense to have them save in repository and source controlled. Today we will see how we can leverage Gitlab Pipeline to setup a continuous deployment for our infrastructure files in three parts: Setup the repository Setup the runner job Deploy the configurations 1. Setup the repository We start first by creating a repository with the same struct

Inspect proxied requests from Nginx to Kestrel with Mitmproxy

Inspect proxied requests from Nginx to Kestrel with Mitmproxy In previous blog posts, we saw how to proxy requests to an ASP NET Core application using Nginx . We saw that request headers also can be proxied with proxy_set_header In order to ease development, we need to be able to debug the values to verify that they are what we expect. Today we will see two methods to inspect the proxied requests. This post will be composed by two parts: Nginx location routing Nginx variable debugging Nginx proxied request debug with Mitmproxy 1 Nginx location routing Considering the following configuration of our server: server { listen 80; location / { proxy_pass http://localhost:5000; } location /api/ { proxy_pass http://localhost:5001/; } } If we want to check whether our location routes are properly configured, we can short circuit the proxy_pass with return and use curl to check whether the location is properly selected. server { listen

SDK-Style project and project.assets.json

SDK-Style project and project.assets.json Last week I encountered an issue with MSBuild while trying to run it from command line. The issue did not appear when using VisualStudio right click + build but only appeared when using msbuild.exe CLI directly with a clean project. Assets file 'C:\[...]\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. When I first saw the error, few questions came to my mind which I will share today in 3 points: Overview of project.assets.json Slim SDK-Style project Mixing SDK-Style project and old projects Special shoutout to @enricosada who provided me with all the answers regarding the SDK-Style project. 1. Overview of project.assets.json project.assets.json lists all the dependencies of the project. It is created in the /obj folder when using dotnet restore or dotnet build as it implicitly calls restore before build, or msbuid.exe /t:restore with msbuild CLI. To simulate dotnet build (re

ApiController attribute in ASP NET Core 2.1

ApiController attribute in ASP NET Core 2.1 ASP NET Core 2.1 brings a set a enhacements for Web API development, Web API being a service accessible via HTTP and returning result in Json format. Those enhancements aim to simplify the composition of those APIs and also remove unecessary functionalities. Today we will explore those enhancements in five parts ControllerBase and ApiController Automatic model validation Inferred model binding ActionResult<T> 1. ControllerBase and ApiController Prior everything, we should set the compatibility version of ASP NET Core by using the .SetCompatibilityVersion . services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1); In the past, we used to inherit from Controller which was providing functions to return different HTTP status code results together with optional data like Ok(...) or Json(...) , but it was also used to display Razor views like View(...) or PartialView(...) . Starting from 2.1, it is now recomm

Update NPM packages for frontend projects with npm-check-updates

Update NPM packages for frontend projects with npm-check-updates Frontend libraries progress very rapidly. After just one month, a project can see all its packages needing an upgrade. Today how we can achieve that in ways: install vs update Using npm-check-updates 1. Install vs Update 1.1 npm install npm install will install packages which are found in package.json but aren’t downloaded. For example, we have a project where we installed Primeng 6.0.0 with npm install --save primeng@6.0.0 . The semantic versioning rule placed in package.json is as followed: "dependencies": { ... some packages, "primeng": "^6.0.0" } The ^ (caret) specifies that minor or patches upgrades are allowed for packages above 1.0.0. For 0.x.x changes, minor changes are considered major therefore only patches upgrades are allowed. Official documentation of the versioning can be found on npm site . If we run npm ls primeng ,