Following on from my much older posts about using ASP.NET Identity 2 to manage user accounts in MVC 4 sites, today I needed to use Identity on an ASP.NET Core MVC site.

As with previous versions, the current Identity library for .NET Core 1.1 uses Entity Framework out-the-box. Luckily it's much easier to change this behaviour for the simplest register/log-in flow.

Install

Firstly you need to get the right NuGet package. For the Identity library without Entity Framework this is:

Microsoft.AspNetCore.Identity

Once this is installed in your project you need to provide your own implementation of the IUserStore<TUser> and IRoleStore<TRole>.

Unlike previous versions the TUser no longer needs to implement a specific interface.

For my project I was using PostgreSQL as the database and Dapper.Contrib as the ORM. My User class was simply:

[Table("\"user\"")]
public class User
{
    [ExplicitKey]
    public Guid Id { get; set; }

    public string UserName { get; set; }

    public string NormalizedUserName { get; set; }

    public string Email { get; set; }

    public string PasswordHash { get; set; }
}

(I had to do some faffing around to make sure the table name was detected correctly in my schema but could have called the table anything, it doesn't have to be called "user").

I've spent a few days getting very in-depth with White for WPF UI automation so in order to store the information while it's still fresh in my mind I am writing a blog post.

White is a framework for automating interactions with desktop Windows applications. It is built on top of the UIAutomation library which is part of the .NET framework. The project is currently not very active on GitHub but despite this it's still very good at dealing with desktop interactions on Windows.

Automate all the things

For this tutorial I've decided to automate interactions with the Visual Studio 2015 application; since it's software that most people interested in following this tutorial will probably have.

I'm creating my application as a .NET 4.6.1 console application. Generally White is used for automated UI tests, so you might be using a test project. Whichever project type you choose the information in this tutorial will still be relevant.

First we need to add the TestStack.White NuGet package. Right click your project and select Manage NuGet Packages:

I've done quite a bit of work with Selenium on and off, mainly for browser automation tests. There are many high quality official libraries for Selenium covering a range of languages. It's an amazing technology and a real joy to work with; however sometimes stuff can go wrong and it's useful to know what's going on under the hood in order to debug where the problem lies.

For this reason I present my very-probably-wrong guide to Selenium.

Gecko, drivers!? What's going on?

There are 3 components in code that interacts with Selenium (ignoring RemoteWebDriver use cases):

1. Your code
2. A driver
3. The browser

For each browser that supports Selenium, the browser vendor provides a "driver". This is usually a small executable (.exe) program tailored for a specific browser:

• Chrome / Chromium
• Firefox
• Edge
• Other drivers available

This driver is the part your code actually interacts with. The driver then communicates with the browser using whatever magic the vendors design. In order to change browsers while using the same code, the drivers expose interfaces/endpoints that implement the WebDriver specification.

Put simply, this means the drivers are a simple RESTful API.

Demo

To demonstrate this I'll use the ChromeDriver version 2.29 which is the latest version at the time of writing. Drivers can only talk to the versions of the browser they are compatible with. In this demo I'm running Chrome on version 58.

Often at work I'll be debugging some incredibly complex logic with lists that can be hundreds, if not thousands, of items long. While the ability to inspect these lists using the normal debugging tools is useful, it gets annoying trying to scroll to the 700th item in a list and then accidentally moving the mouse focus away and having to start again.

For this reason I wanted to look into the possiblity of creating a custom display for certain objects while debugging in Visual Studio. For those of you who have worked with the DataTable you might be familiar with this screen:

This can be accessed by hovering over the object when paused in the debugger and clicking the magnifying glass icon as shown here:

I was recently researching how to read from a COM (Serial) port in order to communicate with an old embedded system. If you're not familiar with them that's one of these:

C# provides the SerialPort class for just this purpose which is hugely helpful. However there's one problem with this class which is that it's just not... very good. I didn't know about this but this post by Ben Voigt should leave you in no doubt that it has some problems.

Setup

In order to test the code on my machine without access to the actual device which was elsewhere, I installed Eltima's Virtual Serial Port Driver which would allow me to test with emulated serial ports. Once I had set up a pair of ports I could send data from one end using PowerShell.