.NET - Renaming a project

If there is one thing that is painfull when using Visual Studio then it is renaming your project. I typically try to keep my projectnames in sync with my current understanding of the business domain. But as I gain new insights, it can happen that I need to rename these projects to align them with the ubiquitous language.

So far, I always used a manual approach where I typically do the following:

• Rename the project file
• Rename the folder
• Change the project references in other project

If there are a lot of projects that should be renamed, it is really cumbersome to do.

Project Renamer to the rescue! This global tool does all the things above (and more) for you.

To use it, first install it as a global tool:

dotnet tool install -g ModernRonin.ProjectRenamer

After the tool is installed, you can use it from the command line, in the directory of your solution:

renameproject <oldProjectName> <newProjectName>

After asking for confirmation, it will rename the project:

D:\Projects\Test\TextGuiApp>renameproject textguiapp filebrowser
Please review the following settings:
Project:                   textguiapp
found at:                  D:\Projects\Test\TextGuiApp\TextGuiApp\TextGuiApp.csproj
Rename to:                 filebrowser
at:                        D:\Projects\Test\TextGuiApp\filebrowser\filebrowser.csproj
VS Solution folder:        none
exclude:
Paket in use:              no
Run paket install:         yes
Run build after rename:    no
Create automatic commit:   yes
Git version:               git version 2.28.0.windows.1

-----------------------------------------------
Do you want to continue with the rename operation? [Enter=Yes, any other key=No]
Analyzing references in your projects - depending on the number of projects this can take a bit...
Project `TextGuiApp\TextGuiApp.csproj` removed from the solution.
Project `filebrowser\filebrowser.csproj` added to the solution.
[master f8d7942] Renamed textguiapp to filebrowser
  3 files changed, 23 insertions(+), 11 deletions(-)
  rename {TextGuiApp => filebrowser}/Program.cs (100%)
  rename TextGuiApp/TextGuiApp.csproj => filebrowser/filebrowser.csproj (100%)

A new git commit was created:

Remark: The tool only works when your code is committed in a (local) GIT repo.

Build GUI console applications through Terminal.Gui

While browsing through GitHub, I stumbled over the following project;

Terminal.Gui - Cross Platform Terminal GUI toolkit for .NET

This is a toolkit library that helps you build cross-platform GUI console apps. It contains a large list of controls for building text user interfaces and even let you use a reactive programming style through support for reactive extensions.

I created a small example that allows you to scroll through all files in the current directory.

• Create a new console application:

dotnet new console

• Add the Terminal.Gui NuGet package:

dotnet add package terminal.gui

• Add your code:

• Run the console app:

dotnet run

 

GraphQL–Upload files using HotChocolate

Originally it was not possible to upload files through GraphQL so typically I used a seperate REST API when I needed support for uploading files.

The main disadvantage of this approach was that it introduced some extra work and that I had to make sure that things like authentication and authorization were handled on both the REST endpoint and the GraphQL endpoint.

With the introduction of the GraphQL Multipart Request specification, this separate endpoint became obsolete and uploading files through your GraphQL server became an option.

Let’s walk through the steps to get this done in HotChocolate:

• I used the HotChocolate template to get started quickly. If you don’t have the template yet, first install it using:

dotnet new -i HotChocolate.Templates.Server

• Now you can bootstrap your application using:

dotnet new graphql

• Register the Upload scalar to support file uploads:
• Create a mutation that uses this scalar to upload the file:
• Register the mutation:
• Invoke the graphQL endpoint:

Remark: The upload scalar is not yet supported in Strawberry Shake or Banana Cake Pop.

ASP.NET Core–Health checks

ASP.NET Core offers Health Checks Middleware for reporting the health of your application. Health checks are exposed as HTTP endpoints and can be probed by container orchestrators and load balancers to check an app's status.

For Kubernetes I typically create 2 type of health checks:

• Readiness indicates if the app is running normally but isn't ready to receive requests.
• Liveness indicates if an app has crashed and must be restarted.

This is a general guideline we use for all containerized applications that we have running in Kubernetes.

Last week I was reviewing one of those applications and I noticed the following code:

This code is perfectly fine, but I couldn’t remember exactly what the role of the Predicate was in the example above. Time to dig in somewhat deeper…

By default, the Health Checks Middleware runs all registered health checks. To run a subset of health checks, you can provide a function that returns a boolean to the Predicate option.

So in the example above, the readiness check will only run healthchecks tagged with ‘ready’. The second health check, the liveness check, will run none of the available health checks.

To tag a specific healthcheck, you should configure this when adding the healthcheck:

More information: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?WT.mc_id=DOP-MVP-5001942

Azure DevOps–Run GraphQL Inspector as part of your build pipeline

I introduced GraphQL Inspector in a previous blog post. Let’s see today how you can integrate it into your Azure DevOps pipeline.

You can do this by adding a command line task that invokes NPX. NPX stands for Node Package Execute and it comes with NPM. It is an npm package runner that can execute any package that you want from the npm registry.

I added a command line task to invoke npx:

Remark: I blogged about NPX before(using GraphQL Inspector as an example).

Something you should really be aware of is the order of the parameters when invoking graphql-inspector. The first parameter should be the existing schema and the second parameter should be the new, updated schema.

Today I accidently switched them around which of course broke the backwards compatibility.

Here is the build output when using the wrong argument order:

And here is the build output after fixing the order:

ASP.NET Core–Mark a web api as deprecated

Versioning of your API’s in ASP.NET Core is easy thanks to the Microsoft.Aspnetcore.Mvc.Versioning nuget package. It allows us to implement versioning with a few configuration lines.

After installing the Nuget you should update the ConfigureServices() method in Startup.cs:

Now you can add the [ApiVersion] attribute on your controller:

If you now have multiple versions of your api, you can decide which version to use by adding an ?api-version=1.0 at the end of your url.

So far nothing new. A feature I only discovered recently is that you can also flag an API as deprecated.  Therefore you need to set an additional Deprecated property on the attribute:

When a client now calls the deprecated API, an extra response header ‘api-deprecated-versions’ is returned:

api-deprecated-versions: 1.0

ASP.NET Core - Configure file upload size limits

By default, ASP.NET Core allows you to upload files up of (approximately) 28 MB  in size. However, for an application I had to update this limit to support files up to 128MB.

Let’s see what should be done to get this working in ASP.NET Core:

Open your Startup.cs and write the following code in the ConfigureServices():

The code above configures the FormOptions and sets the MultipartBodyLengthLimit property to 128MB.

Unfortunately we are not done yet. Depending on if you use Kestrel or host your application in IIS (Express), some extra work is required.

IIS (Express)

For IIS (Express) you need to update your web.config and add the following configuration section:

Kestrel

For Kestrel, you need to add some extra code in your Program.cs file: