Migrating legacy projects to .Net Core/Standard

Introduction After the second version of .NET Core, it is pretty likely to be the future for .NET development, at least for many years. Luckily for legacy projects, Microsoft still continues supporting .NET Framework and developing new versions, such as .NET framework 4.8, which currently available as early access Even though, .NET Core provides some benefits that might be considered to port your legacy projects from .NET Framework to .NET Core. According to this article Choosing between .NET Core and .NET Framework for server apps, these are the points that you should consider to choose between .NET Core or .NET Framework:

Use .NET Core for your server application when:

You have cross-platform needs.You are targeting microservices.You are using Docker containers.You need high-performance and scalable systems.You need side-by-side .NET versions per application.

Use .NET Framework for your server application when:

Your app curren…

Script to clean your Visual Studio solution folder

Sometimes, cleaning your solution folder comes in handy when you want to build from scratch. If you don't do so, you can have unexpected results because of the files generated by your previous builds.

To carried out the cleaning task, I use a simple script which allows me to configure a list of folders I want to remove. This script is divided in two parts. The first part is just a script to check if we have admin permissions. If not, it will display a pop-up to get admin permissions.

You can skip this part, but it is very handy, since the cleaning part might need admin permissions. This part can be very useful for all your scripts, which need admin permissions.

:: BatchGotAdmin :------------------------------------- REM  --> Check for permissions     IF "%PROCESSOR_ARCHITECTURE%" EQU "amd64" ( >nul 2>&1 "%SYSTEMROOT%\SysWOW64\cacls.exe" "%SYSTEMROOT%\SysWOW64\config\system" ) ELSE ( >nul 2>&1 "%SYSTEMROOT%\system…

Why you should migrate your old csproj to SDK format

Introduction  With the introduction of Visual Studio 2017, the format used for csproj was updated including several advantages. This new format will be used when you create a new .Net Core project or .Net Standard library. In spite of the fact that VS2017 continues supporting old csproj format, you can migrate your old projects to SDK format. As a result, you will have the following benefits:

Cleaner csproj files. With new format, a lot of things can be omitted, so your csproj files will be cleaner. Files are included using a wildcard, instead of including every single file. Solution project references are simplier.NuGet reference packages as PackageReferences, so you won't need packages.config and you will be able to use wildcard in your references (for example, 1.0.*).NuGet package definition as a part of the project file. You won't need more nuspec files.Definition of AssemblyInfo attributes in csproj, you won't need more AssemblyInfo.cs files. In addition, you will be…

Maintaining AssemblyInfo for multiple projects

When you are developing an application or manly a NuGet package, you might want to keep the same AssemblyInfo for all your packages, which involves updating each project when you want to publish a new version of your package according to the SemVer convention Semantic Versioning 2.0.0 | Semantic Versioning.

In order to make it easier, with the improvements of dotnet core and the new csproj syntax, which I strongly recommend, MSBuild 15 introduced a pretty cool feature: Solution-wide project properties with Directory.Build.props Customize your build - Visual Studio | Microsoft Docs. Basically, this allows you to define certain properties and use them in all your project in a centralised way, so you don't have to update your projects one by one.

All you have to do is create a new text file named Directory.Build.props and place it where you have your solution file. Here is an example of the properties you can use:


Use Visual Studio extension to distribute your Code Snippets

Introduction In a previous post we saw how you can build code snippets to write tests faster empowering your team to follow good practices.

In this post, we will see how we can distribute our snippets with a Visual Studio extension, which offers different advantages, for example:
You encapsulate your snippets in a VS extension, you you don't need to distribute them independently, and developers don't need to add them to VS one by one. The extension can be updated improving he current snippets or including new snippets.You can add more functionality in your Visual Studio extension.  Creating a new Visual Studio extension First of all, if you have never developed a Visual Studio extension, you might need to install Visual Studio extension development kit. To do it, install this option in your Visual Studio Installer

Create a new Visual Studio extensions project. For this example, I will name it "Snippets…

[Tip] Run Visual Studio as Administrator

Probably you already knew this trick to run apps in Windows 10 as Administrator. If not, I hope this tip can help you.

Sometimes, you need to execute Visual Studio as Administrator always, for example if you are deploying and debugging your application in your Local IIS. To execute VS as Admin there are several ways.

1) Using Sub-menus:
If you go to the item in Windows menu and click on right, you will see menu "More", where you can run VS as administrator.

2) Using shortcuts:
Previous method is slow, so If you don't want to do this each time you open VS, you can create a shortcut in your Desktop and execute it as Administrator. To do this, press right click on the shortcut, click on Advanced and select Run as administrator.

3) Always as Administrator:
Method 2 is much better than 1, but you always have to open VS by using your modified shortcut. So for example, you can not open directly a file .sln with Admin rights. But don't worry, there is a method to execute VS alw…

Writing unit tests faster

Introduction When you are writing tests, the name of the test is very important because the person who is executing the test should be able to detect what was fine or wrong at a glance. For this reason, it is a good practice to follow the convention format:
TestedMethodName_InputData_ExpectedResult By using this format, we can see in a line the method to test, the input used and the result expected, so it will be easy to identify what was wrong.

Another good practice is following the "Arrange", "Act", "Assert" convention (, so when we are reading a test, we can identify easily each part of the test. To make more visible each part, unit test usually include one comment per each state of the test.

Finally, if you are using different test categories, for example to classify unit tests and integration tests, you should use the word TestCategory("YourCategory") in your metadata definition.

Using the snippet In ord…