DEV Community: Alexandre Malavasi

Defining Code Rules for .NET Core projects with NDepend

Alexandre Malavasi — Sat, 11 Jan 2020 04:08:40 +0000

This is the second post related to the NDepend tool and Code Quality for .NET Core application I’m writing. I’m sure it will be many of them, because of how important is this subject, but let’s start with something.

If you want to know more about how to install the NDepend tool in Visual Studio, I recommend you to take a look at my first post about it clicking right:

https://medium.com/@alexandre.malavasi/code-quality-with-ndepend-tool-net-core-854ec070b47d

One of the hardest parts of quality for software projects is to define the code rules for the team, that everyone agrees based on their own experience and based on what the project needs. It does not matter if it is a junior or senior developer, everyone has an opinion, but there is a general agreement on the market about the majority of recommendation we could apply in our projects. Therefore, this post doesn’t have the purpose to define what code rules are recommendable, but the scope for this article is to demonstrate how we can set up the code rules decided by the team on the NDepend tool.

Once you have it installed, the code rules explorer can be found on Extensions >> NDepend >> Code Rules Explorer:

It will be opened a list of all the Rules already set, by category and individually as the image below:

It shows if our project already contains points to review (warnings) by category(e.g Security, Dead Code, etc) and if you click at an individual rule, it is possible to change the configuration or create a new query. Everything here is based on LINQ Queries that you are probably already familiar with.

For this article, I’ll change the rule related to the recommendable maximum number of lines for methods. To do that, just click in an individual rule in the Rule Explorer and it’ll show the LINQ query associated to the rule, as follows:

In my case, I want to put the maximum of lines to 50 (It is not so strict). So, I changed in the LINQ Query the criteria to show the warning related to the rule:

The NDepend tool generates an object (JustMyCode) with useful properties related to our base code information.

You can set patterns for namespace, types, names, properties of the classes, Assemblies and much more. It is really that easy to set up.

The query below is given by the tool as an example in how we can set a rule to avoid to call directly the Db Layer in the View / FrontEnd Layer:

We can check if certain assembly as Entity Framework is being used in a specific layer that we don’t want that someone uses it. Within big teams, it is really important to have this kind of automatic custom verification.

Conclusion
I found the tool really impressive and easy to use, install and setup. Considering the huge amount of useful features this tool has, I think that deserves a series of posts about it, explaining details on how we can get better code quality results easily with this tool help. It is only the second article for a while.

So, I’m really enjoying “playing” with this tool. I hope that will be helpful for you.

Thank you for reading this article till the end.

Migration from Asp.Net Core 2.2 to 3.1 — Real project

Alexandre Malavasi — Thu, 09 Jan 2020 23:33:46 +0000

The purpose of this article is to share my personal experience of migrating a medium complexity real project from Asp.Net Core 2.2 and Asp.Net 3.1.

The project uses the following stack:

Asp.Net Core Web API
Vue JS front-end without any Razor Pages used in the project. The entire front-end is a Vue JS application
Entity Framework Core (Code First approach)
SQL Server Database

At the beginning of my career, almost all the time I decided to postpone the upgrade of .NET projects under my responsibility to the newest version of the underlying technology. There are many factors that should be considered before migrating a system: costs, effort, complexity, business value, etc. Therefore, depends on the scenario, many projects aren’t migrated to a newer version.

I changed my mind in the last years, manly after the launch of the first version of .NET Core. The first migrations from .NET Framework to .NET Core might be problematic for complex projects, but the migrations between .NET Core version, usually, are not that hard.

In the rest of the article, I’m going to demonstrate all the steps I made to migrate a real project, all the problems and, of course, the solutions I’ve found and applied.

Framework version change

The first thing is to change to .NET Core version:

After that, I ran the project just to see the number of errors the Solution would have after this change. And that is the result:

That is saying it got more than 900 errors! The project is not so big and a good amount of the problems are related to the Nuget packages version.

But, my biggest curiosity was the Entity Framework incompatibility issues. So, let's see what I found.

Entity Framework Core

The first thing I did was update all the packages associated with EF Core to avoid the need for too many useless incompatibility issues. I upgraded the packages to the 3.1 version.

Once that was done, I got a problem with the SQL Server library to Entity Framework. The issue was solved by installing the package for SQL Server in separate (Microsoft.EntityFramework.SqlServer):

I built the project again and it sill getting many errors, as follows:

PS: Many of them can be solved just by cleaning the Solution and building it again. I updated again all the packages to the newest version, in case of it exists.

Project file (.csproj)
The next step was to verify the compile errors and warnings reference to project file configuration (.csproj). In my case, after analyzing the compile error messages, I removed the following lines from the file:

According to the official documentation, these entries are useless in .NET Core 3.1.

Nuget package updates
Logically, the next step was to upgrade the rest of the packages used by the application to the newest possible version. In that context, I was using just third party libraries for Vue JS Middleware and native libraries of .NET Core. But, it might be different in your scenario. So, it is really important to analyze it before your own migration.

Startup.cs
The most relevant changes were on the Startup file, because of since version 3.0 of Asp.Net Core, the route configuration changed completely. Now there are more options for specific situations. For instance, you don’t need anymore configure an application to use the entire MVC engine if your application is just a Web API and, therefore, does not use View or Razor Pages. You can add configuration just for Controllers in that case. It is much better I think.

So, the first thing I did in the file was removing the references to Microsoft.AspNetCore.Mvc to use Microsoft.Extensions.Hosting:

Also, instead of use “AddMvc” to set the route configuration, I used “UseEndPoints”, which one is available since the first version of .NET Core 3.0. Using that, I mapped the Controllers, because the backend of my project is a Web API:

The interface IHostEnvironment was replaced by IWebHostEnvironment, as follows:

Extra problems

After finally being able to run the project without errors in compile-time, I quickly get an error in runtime, when it tried to initialize:

I searched in some Github forums and figured out the error was caused by the non-installation of this package:

As I was using a Middleware for Vue JS and running the application as SPA (Single Page Application), the installation of this package was missing. If you use the middleware for Angular or React, possibly you’ll get the same error and that is the solution.

Finally, I was able to run the project, without any extra issues and it worked perfectly.

Conclusion

In my opinion, it is much better to migrate to the 3.1 .NET Core version if the application is already in 2.x version. It is quite stable at this point and one day you’ll have to migrate to it, so why not? I believe it does not contain many break changes. But, surely, I would say that It is always better to check it in your own scenario, that might be different from mine.

I hope this article has helped and encouraged you in case you are thinking to migrate your project to .NET Core 3.1. Thank you for reading this article to the end

How to create project templates and extension for Visual Studio 2019

Alexandre Malavasi — Wed, 08 Jan 2020 21:54:06 +0000

Hi!

Recently, I created two project templates for Vue JS + Asp.Net Core, both of them as Visual Studio 2019 extensions. They were shared on Visual Studio marketplace, as you can see at the link below:

https://medium.com/@alexandre.malavasi/update-template-vue-js-asp-net-core-3-1-visual-studio-2019-caf13caab34b

Would you like to know how to create your own extension and publish your own template? If yes, the rest of the article is a step by step process on how to do that.

Project creation

The first thing you have to do is to create a project that you want to share as a template. In this article, I’ll demonstrate step by step using the Vue JS + Asp.Net Core project I already published.

Project export

Once the project is created, on Visual Studio 2019 go to Project menu option and choose the option “Export Template”:

There are two types of templates: Project template and Item template. As in our case we are creating a project template, I selected the underlying option:

The next step is to configure the name, description, icon that will be shown to users and the image preview. It is really important to set this information properly, as much as high quality you can, because it will appear to final users who will download and install your template/extension.

And uncheck the option “Automatically import to Visual Studio”. In that way, you’ll be able to install the extension that you are creating.
Finally, the process will generate a compact folder which contains the template itself, but it is not the end of the creation:

Tags definition

When we create a new project on Visual Studio 2019, the templates appear together with some specific tags, that help us to filter the templates:

Since the latest version of Visual Studio 2019, these tags are mandatory for those who want to publish an extension. Without those, the extension will be installed, but the template will never be shown in the list, even if the user searches that.

To create these tags, open the compact folder that was generated with the template in the last step and open the .vstemplate file using a Text Editor:

In the section “Template Data”, add after the tag “ProvideDefaultName” the tag list reference to your template, such as platform, project type, language, etc. In my case, I specified as follows:

The full available tag list can be found at the link below:

https://docs.microsoft.com/en-us/visualstudio/ide/template-tags?view=vs-2019#built-in-tags

Creation of the Extension

With the template already created and the tags set, now it is time to create the install file for the extension.

For that, just create a project of the type VSIX Project:

This is the basic structure of the project:
PS: however I created the project name using certain special characters as “+”, just for teaching purposes, please avoid to do that in real scenarios. It is better to create without any empty spaces or special characters, like that: TemplateVueJSAspNetCoreArtigoMedium, instead of the name I put. It will prevent build issues, because of the VS will generate automatically namespaces and classes using that name.

Include in the root the compact folder reference to your template. It is important that the compact folder would contain the .vstemplate file changes with the tags I mentioned before. Don’t forget that.

This project has a manifest file, that will contain the information on the extension e installation instructions.

If you double click in that file, it will be open like a form, which one you can fill in field by field.

Change carefully all the necessary info with quality, because it will appear to final user in the installation and marketplace as well. Also, it is necessary to specify the field “Author” properly, because it is normally has the LAPTOP name.

After that, click at “Assets”:

Remove the existent assets, in case of there are, and click in “New”:

Choose the options that I put and in the path specify the compact folder that you have added to the project.

Generation

To create the installation file, it is just building the project in release mode. It will generate the .exe file used to install the extension on VS.

Done! Our extension was created. You can test it now, before you publish on the Visual Studio marketplace, to see if everything is working fine.

Visual Studio Market Publish

In case you want to publish your extension to the public, you can do that on Visual Studio Marketplace.

To do that go to marketplace.visualstudio.com and, after log in with your Microsoft account, go to the options below:

Upload the .exe of your extension:

Fill in the form with the template and extension info. As that information will be public, pay attention in detail.

Once the process is finished, just save and wait for the approval process. That could take a few minutes.

Conclusion

I hope this article helped you. Thank you for reading it.

[Quick Tip] SignalR — AutoReconnect — Asp.Net Core 3.x

Alexandre Malavasi — Sun, 05 Jan 2020 21:54:08 +0000

SignalR is one of the most important technologies for creating realtime applications or Web functionalities, such as chats, multi-user application interactions or even online games. The purpose of this article is not to demonstrate fully its use or give so many details but talk a little a bit about one big issue SignalR has (or did have): the connection loss.
To exemplify it, I created a simple Asp.Net Core application, which one is a basic chat using SignalR. That is enough to demonstrate it:

As you probably already know, the SignalR keeps an open connection via Websocket between the client and server, as the following image shows:

At this point, it’s being simulated a chat between two users and what happens if the connection is gone? Exactly like that:

One of the most obvious thing in this kink of application is that we have to be aware that issues could (and will) happen, as connection lost and because of that it is pretty recommendable to create mechanisms for handling this in the frontend, providing minimum information to users on what is going on wrong. But, beyond concerns related to user experience, there are a few involved technical questions and concerns.
Everyone who uses regularly SignalR in many projects knows that make reconnection in SignalR without making “tricks” in the code is something not so easy to do depends on the scenario and complexity.
Thinking on that, together with many improvements on .NET Core 3.0, in general, the big update contains new implementations for SignalR as well, since its 6th Preview.

In my opinion, one of the most relevant of that is a method to manage the reconnection between the client and server in case of server issues, instability, unavailability, etc.

As you can see in the image above, there is now an extension method called “WithAutomaticReconnect”, which allows you to configure the intervals that the client will try to reconnect with the server. The default unit is in milliseconds and in the example, I’ve set it to attempt the reconnection after 1 second, 5 seconds, etc. In case you want to stop the attempts, just specify a null value, like I did, indicating to the method that it should finish.
To simulate the connection issue on local, I stopped the application on the local server and, automatically, I started to receive connection error messages. But, after about three seconds I reactivated the server and the connection was established again, successfully.

I hope this quick and simple article had helped a little a bit. Thank you for reading it.