Azure Remote debugging manually in Visual Studio 2017

Often I have (small) pieces of software in Azure. This can be for testing of for real production situation. When you write you code, everything can work perfectly locally and you get strange errors when deployed to Azure. A handy tool is remote debugging where you can connect your Visual Studio Environment to your Azure app.

In this post I will explain how the Remote debugging is setup and what happens under water when you normally just click on “Attach Debugger” in the “Cloud Explorer” of Visual Studio (2017). The sample project is a .NET Core 2.1 Azure Function App.

Enable Remote Debugging

Before we start a debugging session to our Azure Function app we need to enable the functionality.

  1. Navigate in the Azure portal to your function app
  2. Go to the “Application settings”
  3. Under “Debugging” set Remote Debugging to On and set
    Remote Visual Studio version to 2017.

Publish Debug version of application

A Debug version of you application is needed in Azure to connect the breakpoints. Set the “Configuration” in Visual Studio to Debug and publish your application to your function app.

Attach debugger to Function App

In the Cloud Explorer in Visual Studio you can navigate to your Function App and select Attach Debugger.

Many times, this won’t work or you get an error. In example:

You can work around this by attaching the debugger manually in Visual Studio. Follow these steps:

  • Go to the Debug menu and select Attach to Process…
  • Enter the url + port number of your function app in the Connection target field like this:
  • You can find the right port number in this document. In my example it is the port number for Visual Studio 2017. For 2019 it is 4024.
  • When prompt to authenticate, you can do this with the publish profile of your Function App. Download the publish profile by hitting the Get publish profile button in the Azure portal. Use the userName and userPWD of the publish profile.
  • Because it is a .NET Core application, we need to set Attach to to Managed (CoreCLR) code. You can do this with the select button. This isn’t done automatically because of an issue.
  • Last thing is to select the w3wp.exe process and hit Attach.
  • Let Visual Studio download all the files needed en you can debug your application as if you’re working locally.

Apply same validation rules on different classes with FluentValidation

In this blog post I will explain how to apply the same validation rules on the same properties in different classes with FluentValidation. This post will continue on the previous one where I explained how to create Custom Validators for your properties.

So in the previous example we had the Person class with a PersonValidator class. Let’s say you have some pages in your application to create and edit instances of that Person class. In order to create those pages, we use separate ViewModels for those pages. So let’s say you have a PersonCreateViewModel and a PersonEditViewModel. In this way, you have 3 classes with the same validation rules, because in example the property FirstName is the same in all those classes. If the validation rules of the FirstName changes (in example the MaxLength changes) you have to change the rules on 3 different places. If you forget to change it on one place a new bug is introduced.

Reuse validators for property

In order to reuse the validators we are going to extend the static CustomValidators class from our previous post. Again we are creating an extension method but now for the FirstName property. We put all the validation rules that we have for this FirstName in this custom validator. The end result will than be the following:

We can now change the PersonValidator (and PersonCreateViewModel and PersonEditViewModel) to use the power of the new FirstNameValidation extension method. The end result will than be the following:

The PersonValidator class is now smaller and easier to read. The cool thing as well is that you can combine your custom FirstNameValidation extension method with your other extension methods as well. So when you have in example slightly different validation rules for your create and edit viewmodels you can use in example the FirstNameValidation method for the generic rules and add the specific rules in the particular validator class. See the following example where the edit viewmodel has extra validation rules:



Reusing validators saves you a lot of time and duplicate code. This will eventually result in less bugs. Nice is as well that your validator classes like the PersonValidator class is easier to read because it isn’t that long.

Creating custom validators with FluentValidation

This blog post will explain how creating custom validators with FluentValidation. A while back I wrote a blog post about how to start with FluentValidation in your project. In this post we will continue on that foundation.

Let’s say in example you have the class Person.

You need to validate that Person class. So let’s say, you want to validate the FirstName and LastName property. Those properties are similar to each other because both are name and a string so both could have the same (custom) validators. 

So let’s create a PersonValidator class which of course will validate the Person class.

Custom Validator

Now, you want to extend the basic validators. So let’s say you want a validator that the name must not start with a whitespace. You can validate this on multiple ways but the most logical way is to create a custom validator once and use that validator on multiple places.

Here is the validator for checking whitespaces in the begin or end of a string.

You can use the custom validators in the PersonValidator in the following way:

With this above custom validator is validating your objects very easy to do.

In the next blog post we go one step further. I will then show you how to apply the same validation rules on multiple classes.

Use AzureAD PowerShell cmdlets on VSTS agent

Today, I continued working on my custom VSTS extension that I will publish in the near future. In the extension I needed a way how to use AzureAD PowerShell cmdlets on VSTS agent because it isn’t installed by default.

Ship cmdlets in extension

Installing AzureAD cmdlets is not really that difficult. You just download the AzureAD cmdlets module from the PowerShell gallery and put them in your extension so they will be installed with your extension.

Importing the cmdlets

After you put the cmdlets as artifact in your extension, you need to import them. You can do this in example in your execution PowerShell file (in my case Main.ps1) with the following code:


After imported, you can use them. Of course you first need to login. Because we don’t want to hard code credentials in our extension, you will have to pass them to the Connect-AzureAD cmdlet. There are multiple ways on how to do this. Think in example of a credential file as variable. I used an Azure Resource Manager endpoint for this. I did this because I actually only wanted to use the AzureRM module for my extension but some of the cmdlets are only in the AzureAD module.

So how do we login? Connect-AzureAD doesn’t allow to login with a Service Principal and a key. You need to use a self-signed certificate for this what I don’t want. I already have an Azure Resource Manager endpoint with a key. I want to use that key so the login procedures for AzureRM and AzureAD are the same. I already wrote a post on how to login with a SP and key but with an existing Azure Resource Manager endpoint in your task you can use the following code:

After the above code, you can run any cmdlet that you want (if your AzureRM endpoint SP has permission on it).

Connect to AzureAD with Service Principal

I needed this already multiple times but never got it working. Today, I needed again the ability to Connect to AzureAD with Service Principal because some actions can’t be done (yet) via the Azure Resource Manager.

You can’t login into the Azure AD with a key as a Service Principal. You need a certificate for this. Read for more information the documentation of Connect-AzureAD. In order to use a key for logging into the Azure AD, we need to login first into AzureRM because there it is possible by default. Then call something from the Azure AD (in example a group or application) with AzureRM so the tokencache of the AzureRM context is filled with a valid token to “”. After that, use the token to login with Connect-AzureAD AadAccessToken cmdlet.


This script (written in AzureRM 5.1.1 because VSTS hosted agents are using that as well) will get an Azure AD application via AzureRM and then via AzureAD cmdlets.


Upgrading PowershellGet to the latest version

This is a small tutorial on how to upgrade PowershellGet to the latest version. The easiest way to upgrade your PowershellGet module is to run the following command:

After that, check your installed versions:

If you have multiple versions, the best thing todo is to remove the older versions. To remove the older versions, do the following:

  1. Browse to C:\Program Files\WindowsPowerShell\Modules\
  2. Go into C:\Program Files\WindowsPowerShell\Modules\PowershellGet folder, and delete the older version folders
  3. Then do the same for C:\Program Files\WindowsPowerShell\Modules\PackageManagement

Now run the Get-Module commands again and see if the old versions are gone.


Add Azure AD Application as owner of another AD Application

This is just to explain to myself how to add Azure AD Application as owner of another AD Application because I have searched to many times for it.

You can’t do this as Global Admin. You need to be a normal user that is of course owner of the AD Application that you want to change.

This script uses both AzureAD and AzureRM PowerShell modules because on this moment not everything is available in AzureRM.

First get the owners of the application where you want to add the owner to. Check if it’s not already there.

Then get the service principal object id (property id) of the Azure AD Application

The result will be the ApplicationId, DisplayName, Id and Type. Copy the Id property (ObjectId) to add it as owner. You can also use the following shortcut:

Add the new ObjectId as owner:

Check if the new owner is set (you can check this as well in the portal):


Or everything in one line:


FluentValidation in ASP.NET Core

FluentValidation is a wonderful validation package that is around for years. Last week I was busy with a new application in ASP.NET core. I wanted to add some validation and didn’t used FluentValidation in ASP.NET Core before. So I wanted to see if things where changed. This blog post contains some examples from the official FluentValidation Getting started documentation. In the next blog posts I will go into deeper validation of properties and reusing validators in different models.


For integration with ASP.NET Core, install the FluentValidation.AspNetCore package:

Basic validation

Using the package is very easy. Let’s say you have to following class:

You would define a set of validation rules for this class by inheriting from AbstractValidator:

To specify a validation rule for a particular property, call the RuleFor method, passing a lambda expression that indicates the property that you wish to validate. For example, to ensure that the Surname property is not null, the validator class would look like this:

To run the validator, instantiate the validator object and call the Validate method, passing in the object to validate.

The following code would write any validation failures to the console:

Deeper validation

In the next blog posts I will go into deeper validation with custom validators for properties and reusing validators in different models.

DbInitializer dotnet core 2.0

Seed database with users and roles in dotnet core 2.0

In this post I will explain how to seed database users roles dotnet core 2.0 ef. For this we use the UserManager and RoleManager of the AspNetCore Identity framework. In that way, your application already has a default user and role for in example logging into the application. You can use it for test data but also for new installations of your application. In my case I will create a default Administrator user with the Administrator role attached to it for new installations of the application.

Seeding a database in dotnet core 2.0 is different than earlier versions. I followed the basics of the new documentation of Microsoft to get to a good solution. So I first created a new project with the authentication set to Individual Accounts.


In the program.cs class I changed the code to the following:

This is almost the same code as the documentation but I also injected a RoleManager and UserManager so we can create the default user and role for the application. When the instances are created the Initialize method of the DbInitializer is called. This can be used to seed your database.

Because I want to know more information about my users than just their email and username, I extended the ApplicationUser object that is used to create a user in the database with the UserManaer.

I like constructors for new objects so I will use the long constructor to create my default user.


The DbInitializer is the class that is used to seed the database. It is created by the program class. It has a static method Initialize that will be used to pass the external dependencies. The Initialize method will be used to orchestrate all the actions.

First a new Administrator role is created. In my application this is the highest role a user can have. When the role is created, a new default user is created with the earlier provided constructor. After the user is created, the user needs a password to sign into the application. So a password is set. The last step is to connect the user to the Administrator role so he has all the permissions that he needs.

For logging, I use the default logging extension framework provided by dotnet core. I connected Serilog to the logging extension for better control.

Unit testing with xUnit in .NET Core

This post is about Unit testing with xUnit in .NET Core. The last few weeks I was working on a new  project in .NET Core. What I didn’t expected was that so many features weren’t documented or very bad documented. Many articles of Microsoft explained a different solution for the same result. I understand the framework is changing but the documentation should be changing as well then.

So I started unit testing with xUnit. I like the framework a lot so I hoped everything was working in the latest version of .NET Core. What I wanted to achieve was to create of course unit tests but also good integration in Visual Studio and TFS. That was not so easy as I hoped for. It took me a lot of searching and combining of solution to get everything working. Just because of the poor documentation. If you see the result to get this to work then it looks to easy.

First, which version of all the tools and Frameworks did I use:

  • Visual Studio 2017 Enterprise 15.2 (26430.12)
  • ReSharper 2017.1.2
  • dotnet version 1.0.4 (dotnet –version in command prompt)
  • Team Foundation Server 2017 Update 1

When I used the xUnit Nuget package I got with little effort the tests working in Visual Studio. But I wanted more. Because I’m CI/CD engineer, I wanted some automated builds in Team Foundation Server. So I created a new CI build for my project. I couldn’t get everything to work with the tasks that where in TFS so I used the command prompt task. I found this post from xUnit for testing in .NET Core that got me pointing in the right direction.

I installed the following Nuget packages in my project:

This gave me access to the new xunit CLI. I also installed the VS runner package so you could also run the unittests with the “Test Explorer” window in Visual Studio.

Now I could finish my CI Build definition. I removed all the tasks because in every combination that I tried I couldn’t get a part to work. I still wanted, to build the project, run the test, see the results back in Visual Studio and in TFS. As a bonus I wanted to see the Code Coverage of the tests in TFS as well.

First restore all external dependencies:

Then build the project:

Run the tests:

The trick is to use the right configuration and to export the result to an xml file. Place that file in the “$(Build.ArtifactStagingDirectory)” so we can use it in the next step. We already build the solution so add the “-nobuild” option.

Upload the test results:

The Code Coverage was not possible because that is still under development by Microsoft for the .NET Core framework. In the next version of Visual Studio will this be possible. You can already test it in the Visual Studio 2017 15.3 preview version. See this thread on Github for more information.

The result is: