Hello, I am Laszlo

GitHub Actions Template for .NET NuGet packages

10/16/2022

This post outlines the template workflows I use for GitHub Actions to build, test and deploy .NET nuget packages.

It consists of two workflows, CI and CD. As these are templates, each repo will require some level of customization, but the structure remains relatively similar. Each step is denoted the with the current up-to-date version of the action available at the time of writing this post.

Continuous Integration

Continuous Integration (CI) is responsible for builds when new Pull Requests are opened, new commits are pushed, or master gets updated (for example a Pull Request is merged). CI is triggered on push or by workflow_dispatch which means a manual trigger.

Find out more

Even or Odd 2

09/25/2022

In a previous post I have looked into different implementations for deciding if an integer is odd or an even number.

At the time of writing this post, the latest .NET 7 Preview 5 offers a new API to answer the above question. There are two new static abstract methods defined on INumberBase type which is implemented by numerous types including Int32. One can use these methods as static methods on generic type parameters restricted by INumberBase interface or as static methods on implementing types.

For example using it with ints:

public bool StatAbsIsOddOrEven(int number) => int.IsOddInteger(number);

Find out more

ASP.NET Core Blazor application as .NET Tool

09/04/2022

In this post I quickly re-iterate the steps I used to create a dotnet tool. Creating a standard console dotnet tool is easy. As the documentation points out, add the following parameters needed to be added to the csproj:

<PackAsTool>true</PackAsTool>
<ToolCommandName>MyTool</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>

Publish the application as nuget package and upload the created package to NuGet for distribution.

For local testing (without the need for deploying to nuget) one can simply install his/her tool locally by providing a path to the package source:

Find out more

DotNet gRPC Internals

08/14/2022

In the this series of posts I will look into the details of gRPC in ASP.NET Core. In the previous post I created a simple service and a corresponding client. In this posts I will focus on the internal implementation of ASP.NET Core's gRPC extension. gRPC (gRPC Remote Procedure Calls is an open source remote procedure call implementation that is based on modern (web) standards. gRPC leverages HTTP2 as transport protocol, and uses Protocol Buffer as a data format and interface definition language. It is typically used for back channel (service-to-service) communication due to its efficiency. However, the efficiency comes at a cost: debugging/decoding messages are not as straightforward as with other protocols.

The Internals

In this post I will look into how Grpc.AspNetCore nuget package handles gRPC requests. As mentioned in the previous post, the package includes tooling, that generates the base service code for the our real service implementation. During startup AddGrpc() registers dependencies to the DI container, but there is only a handful of classes registered today. The main activity happens during mapping the service with MapGrpcService<T>() call.

Internally this method creates the HTTP call handlers for the service method. Firstly, this method checks if the AddGrpc() call has registered the service dependencies, and delegates the rest of the work to ServiceRouteBuilder<T>. ServiceRouteBuilder<T> is responsible for creating the ASP.NET Core endpoints, which has to be done before app.Run(); is called in Program.cs.

Find out more

.NET Misconceptions

08/05/2022

.NET 7 is released in 2022 autumn. While .NET and C# have been steadily improving with new features year by year, as @markrendle wrote in 2017, .NET has a renaissance. However, non-.NET developers have been hardly keeping up with the framework and the language. Developers familiar only with the 'classic' .NET voice loads of misconceptions about modern .NET itself. This post aims to debunk these ideas.

History

A brief overview about the naming changes that cause confusion for the past years.

• The 'classic' .NET 4.x is referred as .NET Framework these days. At the time of writing this post, the latest release is .NET 4.8. Depending on the minor versions, the Framework is not developed further, only patched with bug and security fixes.

• .NET Core is an initiative of moving .NET Framework to open source. It has been released with version 1, 2 and 3 parallel to .NET Framework releases. The branding of .NET Core is discontinued.

• .NET Standard defines a set of API-s. It is a contract that enables bridging from .NET Framework to .NET Core and .NET 5.

• .NET (5, 6, 7, etc.) is the continuation of .NET Core, while it is also provides a strategy to migrate from .NET Framework. In the rest of the post, when I refer to .NET, I refer to the latest release of this work.

Find out more