michael whelan

Entity Framework Core 1.0.1 Migrations in Separate Assembly

2016-10-30T08:00:00Z

I am getting to grips with Entity Framework Core at the moment and I like what I am seeing so far. There are still a few EF6 scenarios that are not supported yet but the main use cases are supported and there are often workarounds for those that aren't. Entity Framework 1.1 is out soon and features will continue to be added as things just continue to improve. I love the strategic direction the project has taken and, listening to the team discuss the new design, the modular approach and use of dependency injection seems far better, not to mention the massive performance improvements they are already seeing.

When building ASP.Net MVC applications it is quite common to want to store your domain model and data access code in separate class libraries. If this is the case, then ideally you would not even want a reference to Entity Framework Core in your ASP.Net MVC Core project. In this post, I am going to look at how this can be achieved today with the current .Net Core 1.0.1 versions of MVC and EF.

Contoso University ASP.Net MVC Core Sample

I have implemented the first and fourth tutorials of the Contoso sample, which wire up a view to the database and implement migrations in an ASP.Net MVC project, and then migrated the domain model and Entity Framework code to a separate class library. There are no Entity Framework references in the ContosoUniversity MVC project and, instead, the EF dependency is just injected at runtime. You can see the source code on GitHub.

Credit where it is due, I have provided an updated version of solutions from Ben Cull and the EF docs.

Step 1: Configure the class library as an application

{
  "version": "1.0.0-*",

  "buildOptions": {
    "emitEntryPoint": true
  },

  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        }
      }
    }
  },

  "dependencies": {
    "Microsoft.EntityFrameworkCore.SqlServer": "1.0.1",
    "Microsoft.EntityFrameworkCore.SqlServer.Design": {
      "version": "1.0.1",
      "type": "build"
    },
    "Microsoft.EntityFrameworkCore.Tools": {
      "version": "1.0.0-preview2-final",
      "type": "build"
    }
  },

  "tools": {
    "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
  }
}

To convert the class library to a .Net Core application, you have to add the frameworks section above. It is also important that you add a reference to Microsoft.EntityFrameworkCore.Tools in the dependencies and tools sections.

Step 2: Add static void Main

Because this is an application you need to add a Program.cs file to serve as an entry point.

public class Program
{
    public static void Main(string[] args)
    {
    }
}

Step 3: Create a DB Context Factory

The CLI tools would normally discover the DbContext configuration in the Startup.cs of the web application, but the same thing can be achieved by creating a class that implements the IDbContextFactory interface.

public class SchoolDbContextFactory : IDbContextFactory<SchoolContext>
{
    public SchoolContext Create(DbContextFactoryOptions options)
    {
        var builder = new DbContextOptionsBuilder<SchoolContext>();
        builder.UseSqlServer(
            "Server=(localdb)\\mssqllocaldb;Database=MyContosoUniversityCoreDb;Trusted_Connection=True;MultipleActiveResultSets=true");
        return new SchoolContext(builder.Options);
    }
}

Step 4: Configure dependencies with extension methods on IApplicationBuilder and IServiceCollection

There is still one last issue to solve before we can remove the dependency on EF Core from the ASP.Net MVC Core project. The AddDbContext extension method that configures EF Core in Startup.cs still requires a reference to the NuGet package.

services.AddDbContext<SchoolContext>(options => 
    options.UseSqlServer(connectionString));

While most of the samples show how to configure dependencies in Startup.cs, this can quickly become quite unwieldy. I like Scott Allen's suggestion of moving this configuration code into extension methods on IApplicationBuilder and IServiceCollection.

public static class ServiceCollectionExtensions
{
    public static void AddEntityFramework(this IServiceCollection services, string connectionString)
    {
        services.AddDbContext<SchoolContext>(options =>
                options.UseSqlServer(connectionString));
    }
}

I like this approach, because it simplifies Startup.cs to a series of self-documenting, one-line commands, and moves the EF configuration code where it belongs - next to all the other EF code.

Running Migrations for the Class Library

One important point to make, in case it is not obvious, is that you need to run migrations from the class library folder (and not from the web project folder).

Summary

When building ASP.Net MVC applications it is quite common to want to store your domain model and data access code in separate class libraries. If this is the case, then ideally you would not even want a reference to Entity Framework Core in your ASP.Net MVC Core project. In this post, I have shown how this can be achieved today with the current .Net Core 1.0.1 versions of MVC and EF. You can see the source code on GitHub.

Semantic Versioning Tests with PublicApiGenerator

2016-08-07T07:00:00Z

When you are following semantic versioning for the public API of your software package, it can be quite easy to accidentally change the API. Jake Ginnivan wrote the PublicApiGenerator package to generate the public API of your package as a string. That way, you can write a unit test that verifies the contents of the string hasn't changed, using an approval test framework, such as Shouldly or ApprovalTests.

The first thing that you need to do is install the Public Api Generator package into your test project.

Install-Package PublicApiGenerator

Then write a unit test, calling the GetPublicApi method on the static PublicApiGenerator class, passing in the assembly that you want to generate the API for.

[Test]
public void specify_autofac_has_no_public_api_changes()
{
    var publicApi = PublicApiGenerator.PublicApiGenerator.GetPublicApi(typeof(AutofacContainer).Assembly);
    publicApi.ShouldMatchApproved();
}

The test then calls Shouldly's ShouldMatchApproved method, which generates a text file with the contents of the public API string in the form [ClassName].[TestName].received.txt. For example, in this case the file name is SemanticVersioningTests.specifyautofachasnopublicapichanges.received.txt.

[assembly: System.Runtime.CompilerServices.InternalsVisibleToAttribute("Specify.IntegrationTests")]
[assembly: System.Runtime.InteropServices.ComVisibleAttribute(false)]
[assembly: System.Runtime.InteropServices.GuidAttribute("2cb27234-4675-4f6b-b165-052ff7e5fa5e")]
[assembly: System.Runtime.Versioning.TargetFrameworkAttribute(".NETFramework,Version=v4.0", FrameworkDisplayName=".NET Framework 4")]

namespace Specify.Autofac
{  
    public class AutofacContainer : Specify.IContainer, System.IDisposable
    {
        protected Autofac.ContainerBuilder _containerBuilder;
        public AutofacContainer() { }
        public AutofacContainer(Autofac.ILifetimeScope container) { }
        public AutofacContainer(Autofac.ContainerBuilder containerBuilder) { }
        public Autofac.ILifetimeScope Container { get; }
        public bool CanResolve<T>()
            where T :  class { }
        public bool CanResolve(System.Type serviceType) { }
        public void Dispose() { }
        public T Get<T>(string key = null)
            where T :  class { }
        public object Get(System.Type serviceType, string key = null) { }
        public void Set<T>()
            where T :  class { }
        public void Set<TService, TImplementation>()
            where TService :  class
            where TImplementation :  class, TService { }
        public T Set<T>(T valueToSet, string key = null)
            where T :  class { }
    }
    public class AutofacMockRegistrationHandler : Autofac.Core.IRegistrationSource
    {
        public AutofacMockRegistrationHandler(Specify.Mocks.IMockFactory mockFactory) { }
        public bool IsAdapterForIndividualComponents { get; }
        public System.Collections.Generic.IEnumerable<Autofac.Core.IComponentRegistration> RegistrationsFor(Autofac.Core.Service service, System.Func<Autofac.Core.Service, System.Collections.Generic.IEnumerable<Autofac.Core.IComponentRegistration>> registrationAccessor) { }
    }
    public class DefaultAutofacBootstrapper : Specify.Configuration.BootstrapperBase
    {
        public DefaultAutofacBootstrapper() { }
        protected override Specify.IContainer BuildApplicationContainer() { }
        public virtual void ConfigureContainer(Autofac.ContainerBuilder builder) { }
    }
    public class SpecifyAutofacConfigScanner : Specify.Configuration.Scanners.ConfigScanner
    {
        public SpecifyAutofacConfigScanner(Specify.Mocks.IFileSystem fileSystem) { }
        public SpecifyAutofacConfigScanner() { }
        protected override System.Type DefaultBootstrapperType { get; }
    }
}

Because this is the first time the test has been run, the file will be opened in your diff tool so that you can see any changes that have occurred. To make the test pass, just rename "received" to "approved." Now, if the API ever changes, a different API string will be generated in the "received" file and the test will fail, opening your diff tool to show you the changes and allow you to approve them (or change the API back if the change was unintentional). This diagram shows the diff in the Beyond Compare tool.

Summary

Public Api Generator and an approval test framework are a great combination for determining if the public API of your package have changed, allowing you to approve the change if it was intentional, and warning you to revert a change if it was accidental.

Continuous Delivery for .Net Core with GitHub, Cake, GitTools, and AppVeyor

2016-07-31T07:00:00Z

This is an end-to-end tutorial for setting up continuous integration (CI) and continuous delivery (CD) for a .Net Core project hosted on GitHub using Cake, GitTools, and AppVeyor. Credit for this entire process goes to Jake Ginnivan, who set this up for TestStack's BDDfy open source project, and is actively involved in a number of the GitTools projects referenced here. I have replicated that process for another open source project and documented it here.

Continuous delivery can be quite a daunting prospect these days and it would be easy to be overwhelmed by the number of different things the process I describe here does. But, rest assured, I am far from being an expert in this area, so if I can do it you can too. The good news is that the hard work and ingenuity has been done by the folks behind Cake, GitTools, AppVeyor and the other open source tools. They have created all the jigsaw pieces and all that is left for you and me to do is to compose the modules together to suit our particular situation.

Overview

The .Net Core project for this tutorial is Specify: Its technology stack is:

C#: The programming language used for Specify.
NUnit: The testing framework I am using in Specify (though with .Net Core you could have a mix of test frameworks as Cake just delegates to the dotnet-test runner to run tests).
Git and GitHub: The Specify repository is git and the project is hosted on GitHub.
AppVeyor: An online continuous integration server for .Net projects.
NuGet: the package manager for .Net which is where Specify is deployed to.
Cake: A cross platform build automation system with a C# DSL.
GitTools: A GitHub open source organisation which provide a bunch of assorted git related tools which help with debugging, versioning, releasing etc.

That said, many of the topics in this post are more or less applicable to other technologies and providers, mainly due to the agnosticism of the Cake build tool.

The end-to-end process is comprised of these 3 steps, as depicted in the diagram below:

Step 1: Commit code to GitHub

When you commit your code to GitHub, a webhook for AppVeyor is triggered to kick off the continuous integration build. For every project AppVeyor will configure webhooks for its repository to automatically start a build when you push the changes. You can read more about configuring AppVeyor to work with GitHub (and other providers) here.

Step 2: Continuous Integration

AppVeyor runs the Cake continuous integration build process by calling the build.ps1 PowerShell script. This calls the build.cake script, which does all the work, and runs the following tasks (the continuous integration tasks are blue in the diagram):

Build:
- Clean: Cleans the previous build (deleting and re-creating the folder used for build output).
- Semantic Version: Uses GitVersion to calculate the semantic version and update the AssemblyInfo.cs files with that version.
- Package restore: Performs a NuGet package restore.
- Build: Compiles the source code with msbuild.
Test: Runs tests for each of the test projects and for each target in those projects.
Package: generates NuGet packages
- GitHub source stepping: Uses GitLink to allow consumers of this project to step through the exact version of code on GitHub that was used to create the package (an alternative approach to symbol servers).
- Release notes: Uses GitReleaseNotes to automatically generate release notes from the GitHub issue tracker based on closed issues since the last release.
- Package for NuGet:

Step 3: Continuous Delivery

AppVeyor runs the Cake deployment process by calling the deploy.ps1 PowerShell script. This calls the deploy.cake script, which does all the work, and runs the publish tasks (green on the diagram above): Manually run the deploy process, etc.

Cake

Cake (C# Make) is a cross platform build automation system with a C# DSL to do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages. It is built on top of the Roslyn and Mono compiler which enables you to write your build scripts in C#. One of its main philosophies is that Cake should behave the same way regardless of operating system (Windows, Linux, or OS X) or environment (AppVeyor, VSTS, TeamCity, Jenkins, etc.).

You can read how to get started with Cake here.

Tasks represent a unit of work in Cake, and you use them to perform specific work in a specific order. You can read more about tasks here.

Cake supports something called script aliases. Script aliases are convenience methods that are easily accessible directly from a Cake script. Every single DSL method in Cake is implemented like an alias method. You can read more about Cake aliases here.

GitTools

GitTools is a GitHub open source organisation which provide a bunch of assorted git related tools which help with debugging, versioning, releasing etc.

GitVersion: Provides easy, automated, semantic versioning for projects using git, by looking at your git history and working out the semantic version of the commit being built.
GitLink: Allows users to step through your source code hosted on GitHub, making symbol servers obsolete.
GitReleaseNotes: Utility which makes it really easy to generate release notes for your git project. Works with GitHub, Jira and YouTrack.

Continuous Integration

Build task

This illustrates a basic Cake task. You can see that it is familiar C# syntax. Each task defines a name - "Build" in this case - and is followed by a .Does method which takes a lambda for the work the task will perform.

The IsDependentOn method is used to setup a dependency on another task. That means that task must run before this task. If there are multiple dependencies then each will run in order before this task. So, in this example, they will run in the following order:

Clean => Version => Restore => Build.

The build task uses the Cake MSBuild task to compile the Specify solution.

Task("Build")
    .IsDependentOn("Clean")
    .IsDependentOn("Version")
    .IsDependentOn("Restore")
    .Does(() => {
        MSBuild("./src/Specify.sln");
    });

In order to use the commands for this alias, MSBuild will already have to be installed on the machine the Cake Script is being executed on.

Clean task

The first task you normally want to do with a build script is to delete the working directory, which various tasks in the build process use for preparing files and producing output. Cake provides a number of aliases for working with directories. This script uses the DirectoryExists, DeleteDirectory, and CreateDirectory methods.

Task("Clean")
    .Does(() => {
        if (DirectoryExists(outputDir))
        {
            DeleteDirectory(outputDir, recursive:true);
        }
        CreateDirectory(outputDir);
    });

Version task

The version task uses the GitVersion tool to calculate the semantic version of the project and updates the project's project.json and AssemblyInfo.cs files with this version number. You can read more about GitVersion on the project's readthedocs site.

In order to use the GitVersion tool, you have to download its package as part of executing the build script. To do that with Cake, you have to provide this directive at the top of the build script.

#tool "nuget:?package=GitVersion.CommandLine"

And then use the GitVersion alias and the GitVersionSettings class in the version task.

Task("Version")
    .Does(() => {
        GitVersion(new GitVersionSettings{
            UpdateAssemblyInfo = true,
            OutputType = GitVersionOutput.BuildServer
        });
        versionInfo = GitVersion(new GitVersionSettings{ OutputType = GitVersionOutput.Json });
        // Update project.json
        var updatedProjectJson = System.IO.File.ReadAllText(specifyProjectJson)
            .Replace("1.0.0-*", versionInfo.NuGetVersion);

        System.IO.File.WriteAllText(specifyProjectJson, updatedProjectJson);
    });

Restore task

Cake provides built-in support for .Net Core. The DotNetCoreRestore alias will restore all NuGet packages for .Net Core solutions. You just have to pass in the folder where the solution is located ("src" in this example).

Task("Restore")
    .Does(() => {
        DotNetCoreRestore("src");
    });

In order to use the commands for this alias, the .Net Core CLI tools will need to be installed on the machine where the Cake script is being executed.

Test task

DotNetCoreTest is another DotNetCore alias. It will use the .Net CLI test runner that is configured for each test project to run the tests for that project. It will run tests for each target defined in the test project's project.json file. You just have to pass in the location of the test project.

DotNetCoreTest("./src/tests/Specify.Tests");
DotNetCoreTest("./src/tests/Specify.IntegrationTests");
DotNetCoreTest("./src/Samples/Examples/Specify.Examples.UnitSpecs");

In order to use the commands for this alias, the .Net Core CLI tools will need to be installed on the machine where the Cake script is being executed.

Package task

The package task performs performs several operations to create runs once for each

GitHub source stepping task

UPDATE: Unfortunately, it turns out that GitLink does not currently support xproj or project.json and .Net Core. I will leave this step in as it is still a correct description of how to use Cake and GitLink with pre-.Net Core projects and perhaps suppor will be added eventually. As an alternative, I will demonstrate packaging pdb files as a NuGet package for a symbol server in a later step.

In order to use the GitLink tool, you have to download its package as part of executing the build script.

#tool "nuget:?package=gitlink"

And then use the GitLink alias and the GitVersionSettings class in the package task. This example shows how to include command-line arguments that tell GitLink which projects in the solution to target.

GitLink("./", new GitLinkSettings { ArgumentCustomization = args => args.Append("-include Specify,Specify.Autofac") });

Alternatively, you can just call it without any settings and accept the defaults:

GitLink("./");

Release notes task

In order to use the GitReleaseNotes tool, you have to download its package as part of executing the build script.

#tool "nuget:?package=GitReleaseNotes"

Although there is a GitReleaseNotes tool for Cake, this example shows how to use the StartProcess alias to run the GitReleaseNotes executable that Cake has downloaded to the tools directory.

private void GenerateReleaseNotes()
{
    var releaseNotesExitCode = StartProcess(
        @"tools\GitReleaseNotes\tools\gitreleasenotes.exe", 
        new ProcessSettings { Arguments = ". /o artifacts/releasenotes.md" });
    if (string.IsNullOrEmpty(System.IO.File.ReadAllText("./artifacts/releasenotes.md")))
        System.IO.File.WriteAllText("./artifacts/releasenotes.md", "No issues closed since last release");

    if (releaseNotesExitCode != 0) throw new Exception("Failed to generate release notes");
}

Package for NuGet task

The package task generates the .nupkg files for each project that needs to be deployed to NuGet using Cake's DotNetCorePack alias. This is another DotNetCore alias, and also requires the .Net Core CLI tools be installed on the machine where the Cake script is being executed.

private void PackageProject(string projectName, string projectJsonPath)
{
    var settings = new DotNetCorePackSettings
        {
            OutputDirectory = outputDir,
            NoBuild = true
        };

    DotNetCorePack(projectJsonPath, settings);

    System.IO.File.WriteAllLines(outputDir + "artifacts", new[]{
        "nuget:" + projectName + "." + versionInfo.NuGetVersion + ".nupkg",
        "nugetSymbols:" + projectName + "." + versionInfo.NuGetVersion + ".symbols.nupkg",
        "releaseNotes:releasenotes.md"
    });
}

Note that this also generates the symbols package for uploading the .pdb files to a symbol server (as an alternative to GitHub source stepping).

If the script is running on AppVeyor then it copies all the generated output to the Artifacts folder on AppVeyor that is associated with this build.

Final Cake Continuous Integration build script

Having seen all the constituent parts it's probably useful to see the whole script:

#tool "nuget:?package=GitReleaseNotes"
#tool "nuget:?package=GitVersion.CommandLine"
#tool "nuget:?package=gitlink"

var target = Argument("target", "Default");
var outputDir = "./artifacts/";
var solutionPath = "./src/Specify.sln";
var specifyProjectJson = "./src/app/Specify/project.json";
var specifyAutofacProjectJson = "./src/app/Specify.Autofac/project.json";

Task("Clean")
    .Does(() => {
        if (DirectoryExists(outputDir))
        {
            DeleteDirectory(outputDir, recursive:true);
        }
        CreateDirectory(outputDir);
    });

Task("Restore")
    .Does(() => {
        DotNetCoreRestore("src");
    });

GitVersion versionInfo = null;
Task("Version")
    .Does(() => {
        GitVersion(new GitVersionSettings{
            UpdateAssemblyInfo = true,
            OutputType = GitVersionOutput.BuildServer
        });
        versionInfo = GitVersion(new GitVersionSettings{ OutputType = GitVersionOutput.Json });
        // Update project.json
        var updatedProjectJson = System.IO.File.ReadAllText(specifyProjectJson)
            .Replace("1.0.0-*", versionInfo.NuGetVersion);

        System.IO.File.WriteAllText(specifyProjectJson, updatedProjectJson);
    });

Task("Build")
    .IsDependentOn("Clean")
    .IsDependentOn("Version")
    .IsDependentOn("Restore")
    .Does(() => {
        MSBuild(solutionPath);
    });

Task("Test")
    .IsDependentOn("Build")
    .Does(() => {
        DotNetCoreTest("./src/tests/Specify.Tests");
        DotNetCoreTest("./src/tests/Specify.IntegrationTests");
        DotNetCoreTest("./src/Samples/Examples/Specify.Examples.UnitSpecs");
    });

Task("Package")
    .IsDependentOn("Test")
    .Does(() => {
        //GitLink("./", new GitLinkSettings { ArgumentCustomization = args => args.Append("-include Specify,Specify.Autofac") });

        GenerateReleaseNotes();

        PackageProject("Specify", specifyProjectJson);
        PackageProject("Specify.Autofac", specifyAutofacProjectJson);

        if (AppVeyor.IsRunningOnAppVeyor)
        {
            foreach (var file in GetFiles(outputDir + "**/*"))
                AppVeyor.UploadArtifact(file.FullPath);
        }
    });

private void PackageProject(string projectName, string projectJsonPath)
{
    var settings = new DotNetCorePackSettings
        {
            OutputDirectory = outputDir,
            NoBuild = true
        };

    DotNetCorePack(projectJsonPath, settings);

    System.IO.File.WriteAllLines(outputDir + "artifacts", new[]{
        "nuget:" + projectName + "." + versionInfo.NuGetVersion + ".nupkg",
        "nugetSymbols:" + projectName + "." + versionInfo.NuGetVersion + ".symbols.nupkg",
        "releaseNotes:releasenotes.md"
    });
}    

private void GenerateReleaseNotes()
{
        var releaseNotesExitCode = StartProcess(
        @"tools\GitReleaseNotes\tools\gitreleasenotes.exe", 
        new ProcessSettings { Arguments = ". /o artifacts/releasenotes.md" });
    if (string.IsNullOrEmpty(System.IO.File.ReadAllText("./artifacts/releasenotes.md")))
        System.IO.File.WriteAllText("./artifacts/releasenotes.md", "No issues closed since last release");

    if (releaseNotesExitCode != 0) throw new Exception("Failed to generate release notes");
}

Task("Default")
    .IsDependentOn("Package");

RunTarget(target);

AppVeyor badge

A project status badge is a dynamically generated image displaying the status of the last AppVeyor build. You can put a status badge on the home page of your GitHub project (in the readme.md file).

[![Build status](https://ci.appveyor.com/api/projects/status/vj6ec2yubg8ii9sn?svg=true)](https://ci.appveyor.com/project/mwhelan/specify)

You can read more about AppVeyor status badges here.

Continuous Delivery

I have not had time to replicate the BDDfy deployment to NuGet process, so I will just outline the steps we take to deploy BDDfy.

The process has two steps, each of which has its own project in AppVeyor. The first step is to create a GitHub release. That is done by the CI build, which is configured to not build tags. The second step is to deploy to NuGet. This is done by a dedicated AppVeyor project for deployment which is configured to only build tags. Tags are created when you publish the GitHub Release.

Step 1: Publish a GitHub Release

The deployment process starts by selecting Deploy from the continuous integration build to create a new deployment.

Select Create GitHub Release - GitHub Releases option for the Environment and then click Deploy.

This will run and generate a GitHub Release.

Now, if you go over to GitHub Releases for your project you should see a new Draft Release.

At this stage, this requires some manual editing of the title and tag and perhaps making some changes to the release notes.

Once everything is OK, publish the GitHub Release. This will create a tag, which will kick off the AppVeyor deployment project (which is configured to only build tags).

Step 2: Deploy to NuGet

The BDDfy deployment process is defined in the deploy.cake file. It downloads GitHub Release artifacts and then deploys to NuGet.

Summary

So, that is an end-to-end process for setting up continuous integration and continuous delivery for a .Net Core project hosted on GitHub using Cake, GitTools, and AppVeyor. It is one of my longer posts, and there's a whole lot going on, but hopefully it provides some useful insight into some of the great tools that talented people have made available for the community and how you might be able to use them in your own processes.

Testing .Net Core with TestDriven.Net

2016-07-22T07:00:00Z

Third party tools vendors are finding it particularly difficult to provide .Net Core support while the tooling is in preview and still subject to a lot of change, but TestDriven.Net is leading the way with a slick Visual Studio testing experience for .Net Core (and earlier versions of .Net). You simply right click on the solution, project, folder, file, or test, and it will run all of the tests in that scope. TestDriven.Net is actually one of the oldest .Net/Visual Studio test runners and is undergoing something of a reboot with support for .Net Core and the next version of Visual Studio, "15."

TestDriven.Net v4 Alpha

Jamie Cansdale, the maintainer of the venerable TestDriven.Net, has been hard at work releasing a number of alpha versions through the testdriven.net website. The releases consist of .zip files that contain a setup.exe executable for installing TestDriven.Net as a Visual Studio add-in.

You can read the release notes here.

Running Tests

TestDriven.net is extremely flexible and can be run in a number of ways.

Running Tests from Solution Explorer

After installing TestDriven.Net, and re-starting Visual Studio, the 'Run Test(s)' command becomes available on the Right-Click context menu in Solution Explorer, and offers a straightforward way to build and run tests. You can right click on the solution, a project (or multiple projects), or a file (or multiple files) and it will run all of the tests in that scope. You have a number of useful testing options, such as testing with the debugger or code coverage.

This is intended to be the default method of test execution in most contexts. TestDriven.Net automatically detects the test framework being used and executes tests using the correct test runner. The tests are launched by a test execution engine running as an external process. This test process is kept alive in order to improve execution times on subsequent runs. Once a test process has been cached, a rocket icon will appear in the notify box.

Running Tests from the Code Editor Window

If the code editor window is selected, the test(s) to execute will be determined by the position of the caret:

individual tests are executed by right-clicking anywhere inside a test method and selecting 'Run Test(s)'
all tests in a test fixture are executed by right-clicking inside a class (but outside of any method) and selecting 'Run Test(s)'
all tests in a namespace are executed by right-clicking inside a namespace and selecting 'Run Test(s)'.

Test Results

Once your run the tests, TestDriven.Net will show the results in the "Test" output window.

Tips and Tricks

It is important to remember that TestDriven.Net v4 is an alpha, and not everything works quite as well as it will in the final release. This is sometimes down to the vagaries of how Visual Studio works, not to mention the issues that all tools vendors are facing with the moving target of the Visual Studio .Net Core preview tooling. So, hopefully some of these things will improve with time.

The order of frameworks matter when multi-targeting

If you are targeting multiple frameworks in your test project and you put the .Net 4x project first, TestDriven.Net won't run your tests. It is important to put the .Net Core framework first in your project.json. For example, here netcoreapp1.0 is listed before net46.

"frameworks": {
    "netcoreapp1.0": {
        "dependencies": {
            "Microsoft.NETCore.App": {
                "type": "platform",
                "version": "1.0.0"
            },
            "System.Linq": "4.1.0"
        },
        "imports": [
            "dnxcore50",
            "portable-net45+win8"
        ]
    },
    "net46": {
        "dependencies": {
        },
        "buildOptions": {
            "define": [
                "Approvals",
                "Culture",
                "NSubstitute"
            ]
        }
    }

Runtimes

I had an issue where some of my tests just weren't working. When I ran them nothing would happen - nothing was displayed in the "Test" output window and the status bar said 0 passed, 0 Failed, 0 Skipped. It turned out the problem was having a Runtimes node in my test project's project.json.

"runtimes": {
    "win10-x64": {}
},

This made Visual Studio incorrectly report to TestDriven.Net that my test project's DLL was in the bin\Debug\netcoreapp1.0\win10-x64 directory, when in fact it was in the bin\Debug\netcoreapp1.0 directory. Removing the runtimes node solved the problems and enabled TestDriven.Net to run the tests successfully.

Execute non-test methods

The .NET Core test runner requires that unit tests be inside a Console Application project, but TestDriven.Net can actually execute any method/property that doesn't have a test attribute as an "Ad hoc" test (even if it's inside a Class Library project). Anything returned from the method/property will be expanded on the output window.

This feature can make it a really interesting utility for running your own methods. For example, if you wanted to find out more about the properties on a type:

Get Involved

TestDriven.Net is still in alpha and Jamie Cansdale is actively looking at ways to make it as useful as possible. That means that you have the opportunity to shape its direction by raising issues on the GitHub issues page or tweeting Jamie with feature requests. Give it a try.

For example, Jamie mentioned to me that he is thinking about how to allow people to swap between the different frameworks. At the moment he is thinking of adding separate Test With > .NET Core and Test With > .NET 4.x options, but he would appreciate feedback and suggestions about how this might work best.

Summary

There are not a lot of .Net Core test runners available at the moment. TestDriven.Net may only be in alpha, but it is already very stable for day-to-day testing of your .Net Core projects and is a slick and flexible way to run your tests in Visual Studio. I recommend checking it out.

A Humanizer Display Metadata Provider for ASP .Net Core

2016-07-18T07:00:00Z

I have always been a big fan of using a Humanizer model metadata provider in my ASP.Net MVC applications. This means that Humanizer will automatically put spaces into labels for multi-word view model property names rather than the developer having to manually add a lot of data annotation Display attributes to those view model property names. The APIs have changed a little for ASP.Net Core, but the approach is basically the same.

What it does

You can read about the approach for classic MVC in Mehdi's introductory Humanizer post. Basically, instead of the ReleaseDate label:

you get the preferable Release Date, with a space between the words.

How it works

Rather than inherit from the DataAnnotationsModelMetadataProvider as you did in classic MVC, with ASP.Net Core you need to implement the IDisplayMetadataProvider interface from the Microsoft.AspNetCore.Mvc.ModelBinding.Metadata namespace. The implementation is otherwise very similar:

using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using Humanizer;
using Microsoft.AspNetCore.Mvc.ModelBinding.Metadata;

public class HumanizerMetadataProvider : IDisplayMetadataProvider
{
    public void CreateDisplayMetadata(DisplayMetadataProviderContext context)
    {
        var propertyAttributes = context.Attributes;
        var modelMetadata = context.DisplayMetadata;
        var propertyName = context.Key.Name;

        if (IsTransformRequired(propertyName, modelMetadata, propertyAttributes))
        {
            modelMetadata.DisplayName = () => propertyName.Humanize().Transform(To.TitleCase);
        }
    }

    private static bool IsTransformRequired(string propertyName, DisplayMetadata modelMetadata, IReadOnlyList<object> propertyAttributes)
    {
        if (!string.IsNullOrEmpty(modelMetadata.SimpleDisplayProperty))
            return false;

        if (propertyAttributes.OfType<DisplayNameAttribute>().Any())
            return false;

        if (propertyAttributes.OfType<DisplayAttribute>().Any())
            return false;

        if (string.IsNullOrEmpty(propertyName))
            return false;

        return true;
    }
}

To wire it up, you configure it in the ConfigureServices method of Startup.cs. You add the custom HumanizerMetadataProvider provider to the ModelMetadataDetailsProviders collection.

services.AddMvc()
    .AddMvcOptions(m => m.ModelMetadataDetailsProviders.Add(new HumanizerMetadataProvider()));

Summary

Creating a custom model metadata provider in ASP.Net Core is quite similar to ASP.Net MVC, but the APIs have changed a little bit.

The State of .Net Core Testing Today

2016-07-17T07:00:00Z

.Net Core 1.0 has been officially released but the tooling is still in preview. This means that a number of open source testing libraries have been able to release at least alpha support for .Net Core, but it is not always easy to locate and you sometimes have to drill through GitHub issues, stack overflow questions, and NuGet feeds, to find it. Third party tools vendors are finding it particularly difficult to provide .Net Core support while the tooling is in preview and still subject to a lot of change, but TestDriven.Net has a number of promising alpha releases. In this post, I am going to look at the main .Net testing providers, their current support for .Net Core, and how you can get hold of them.

Test Project Configuration

The steps to create a test project are a little bit different with .Net Core. You still create it as a class library, but now you must mark it as a .Net Core Application (the netcoreapp1.0 framework in the project.json below).

"frameworks": {
    "netcoreapp1.0": {
        "dependencies": {
            "Microsoft.NETCore.App": {
                "type": "platform",
                "version": "1.0.0"
            }
        }
    }
}

When using the .Net CLI for testing, unit test projects are actually an application, not a class library.If you forget to make this change, the compiler will tell you that dotnet-test-xunit (for example) is not compatible with your class library project.

You must also add a project reference to the application project you are testing in the project.json.

"dependencies": {
    "Specify.Autofac": {
      "target": "project"
    },

You can target both net4xx and netcoreapp simply by adding both frameworks together in your project.json file. When you run dotnet test with multiple framework entries, the system will run all your framework tests, one after the other.

"frameworks": {
    "netcoreapp1.0": {
        "dependencies": {
            "Microsoft.NETCore.App": {
                "type": "platform",
                "version": "1.0.0"
            },
            "System.Linq": "4.1.0"
        },
        "imports": [
            "dnxcore50",
            "portable-net45+win8"
      ]
    },
  "net46": {
    "dependencies": {
    },
    "buildOptions": {
      "define": [
        "Approvals"
      ]
    }
  }
},

Test Runners

Unfortunately, my favourite test runners, ReSharper and NCrunch, do not have support for .Net Core yet. That has meant that we have been stuck with either the console runners or the Visual Studio test runner. Fortunately, things are looking up, with TestDriven.Net providing a flurry of alpha packages. There are still a number of issues to work out - tests just flat out don't run on some of my projects - but it seems to be shaping up quite well and is a great option for those projects that it does work for.

TestDriven.Net v4 Alpha

Jamie Cansdale, the maintainer of the venerable TestDriven.Net, has released a number of alpha versions through the testdriven.net website. The releases consist of .zip files that contain an executable for installing TestDriven.Net as a Visual Studio add-in.

After installing TestDriven.Net, you can right click on the solution, a project (or multiple projects), or a file (or multiple files) and it will run all of the tests in that scope. TestDriven.Net automatically detects the test framework being used and executes tests using the correct test runner. You have a number of useful testing options, such as testing with the debugger or code coverage.

I've written another post about how to test .Net Core with TestDriven.Net here.

Console Runners

The various test frameworks implement the .Net Core test protocol to provide test runners, which allow tests to be run by the Visual Studio test runner or from the command line.

To run tests from the command line, open a command prompt or PowerShell command window. In the window, navigate to the folder containing the source code of your test project. To run the .Net CLI test runner, type dotnet test, as shown below:

> dotnet test
xUnit.net .NET CLI test runner (64-bit .NET Core win10-x64)
  Discovering: MyFirstDotNetCoreTests
  Discovered:  MyFirstDotNetCoreTests
  Starting:    MyFirstDotNetCoreTests
    MyFirstDotNetCoreTests.Class1.FailingTest [FAIL]
      Assert.Equal() Failure
      Expected: 5
      Actual:   4
      Stack Trace:
        C:\Samples\MyFirstDotNetCoreTests\src\MyFirstDotNetCoreTests\Class1.cs(16,0): at MyFirstDotNetCoreTests.Class1.FailingTest()
  Finished:    MyFirstDotNetCoreTests
=== TEST EXECUTION SUMMARY ===
   MyFirstDotNetCoreTests  Total: 2, Errors: 0, Failed: 1, Skipped: 0, Time: 0.167s

This will kick off the tests using whichever runner is specified in the testRunner node in project.json.

Run tests in Visual Studio

The same NuGet package which allows you to run tests from the console also allows you to run tests from within Visual Studio. Show the Test Explorer window by choosing Test > Windows > Test Explorer. The Test Explorer window will show inside Visual Studio, and your test should be visible (if they're not, try building your project to kick off the test discovery process).

If you click the Run All link in the Test Explorer window, it will run your tests and show you success and failure. You can click on an individual test result to get failure information as well as stack trace information:

ReSharper

ReSharper does not have test runner support for .Net Core yet.

NCrunch

NCrunch does not have test runner support for .Net Core yet. Remco Mulder, NCrunch's creator, has a useful explanation here on the difficulties that tool vendors face with the ongoing changes to tooling.

Test Frameworks

xUnit

xUnit has beta support for .Net Core. In your project.json, you need to set the testRunner to xunit and add dependencies for xUnit and the dotnet-test-xunit console runner.

"testRunner": "xunit",
"dependencies": {
    "xunit": "2.2.0-beta2-build3300",
    "dotnet-test-xunit": "2.2.0-preview2-build1029"
},

Using the NuGet Package Management Console:

Install-Package xunit -Pre
Install-Package dotnet-test-xunit -Pre

NUnit

NUnit also has beta support for .Net Core. In your project.json, you need to set the testRunner to nunit and add dependencies for NUnit and the dotnet-test-nunit console runner.

"testRunner": "nunit",
"dependencies": {
    "NUnit": "3.4.1",
    "dotnet-test-nunit": "3.4.0-beta-1"
},

Using the NuGet Package Management Console:

Install-Package Nunit
Install-Package dotnet-test-nunit -Pre

MsTest

Microsoft's own MsTest also has support for .Net Core. In your project.json, you need to set the testRunner to mstest and add dependencies for MSTest.TestFramework and the dotnet-test-mstest console runner.

"testRunner": "mstest",
"dependencies": {
    "MSTest.TestFramework": "1.0.0-preview",
    "dotnet-test-mstest": "1.0.1-preview"
},

Using the NuGet Package Management Console:

Install-Package MSTest.TestFramework -Pre
Install-Package dotnet-test-mstest -Pre

MSpec

MSpec is a context/specification framework that greatly influenced the way I write tests today. I really like its class per test approach and the automocking that you can do with it, both of which I have carried forward. I only moved away from it because it was so different from how I was writing my functional tests with BDDfy, and I wanted to use the same frameworks and coding styles across all my tests.

Ivan Zlatev has a great post outlining MSpec support for .Net Core here.

BDDfy

BDDfy, from TestStack - the simplest BDD framework to use, customize and extend - has full support for .Net Core.

Install-Package TestStack.BDDfy

Fixie

As described in the Project Roadmap, Fixie 2.x is being actively developed on the dev branch to support .NET Core. Fixie itself should leverage .NET Core, and it should allow testing of projects that leverage .NET Core.

For more detailed progress and discussion on .NET Core, see Issue #145 - Support .NET Core.

One of the items on the roadmap is to publish a prerelease NuGet package of 2.x for initial round of feedback but, as far as I can tell, that has not been released yet.

Fixie's creator, Patrick Lioi, has more details on Fixie 2.0's progress on his blog, including a link to a video presentation he did about it.

Mocking Frameworks

Most of the mocking frameworks depend on Castle.Core, which itself currently has alpha support for .Net Core. Note, that at the time of writing, Castle.Core had a dependency on System.Diagnostics.TraceSource, meaning the mocking frameworks also had this dependency. As Jonathon Rossi says in the comments below, Castle.Core have since released Castle Core 4.0.0-beta001, which removes that dependency, so expect this dependency to drop off the mocking frameworks once they update to the latest Castle.Core.

NSubstitute

If you go to nuget.org, you will find that the latest NSubstitute package is version 1.10.0 from March and does not have support for .Net Core. However, there is actually an unlisted beta package of version 2.0 with support for .Net Core that is published to nuget.org and just not visible.

You can install the package via the NuGet CLI with the following command:

Install-Package NSubstitute -Version 2.0.0-beta -Pre

Or you can just add these references to the dependencies node of your project.json. Note that you also need to add a reference to System.Diagnostics.TraceSource.

"NSubstitute": "2.0.0-alpha003",
"System.Diagnostics.TraceSource": "4.0.0",

You can follow the progress of NSubstitute 2.0 on this GitHub issue or on Alexandr Nikitin's branch.

FakeItEasy

FakeItEasy also don't have a package with .Net Core support officially published on NuGet, but you can access the alpha version of v2.3, with support for .Net Core, on an appveyor NuGet feed:

https://ci.appveyor.com/nuget/fakeiteasy-jeremymeng

To access this from your solution, just add this reference as a NuGet package source in Visual Studio and add a NuGet.config to the root of your solution like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="appveyor FakeItEasy" value="https://ci.appveyor.com/nuget/fakeiteasy-jeremymeng" />
  </packageSources>
</configuration>

And add a reference to the latest version (2.2.0-coreclr-alpha30 at the time of writing) in the dependencies node of project.json.

"FakeItEasy": "2.2.0-coreclr-alpha30",

You can follow the progress of this release on this GitHub issues page.

Moq

Moq has an alpha release published to NuGet.org with support for .Net Core:

Install-Package Moq -Pre

And, like NSubstitute, it seems you also need to add a reference to System.Diagnostics.TraceSource in your project.json. You can read more about that on stack overflow.

"moq.netcore": "4.6.25-alpha",
"System.Diagnostics.TraceSource": "4.0.0"

Assertion Frameworks

Fluent Assertions and Shouldly both have full support for .Net Core.

Other Testing Libraries

As far as I can tell, ApprovalTests does not have support for .Net Core yet.

Summary

.Net Core 1.0 has been officially released but the tooling is still in preview. This means that a number of open source testing libraries have been able to release at least alpha support for .Net Core, but it is not always easy to locate. In this post, I have looked at the main .Net testing providers, their current support for .Net Core, and how you can get hold of them.

Replacing AppDomain in .Net Core

2016-07-07T07:00:00Z

In the move to .Net Core, Microsoft decided to discontinue certain technologies because they were deemed to be problematic. AppDomain was one of those that did not make the cut. While AppDomains have been discontinued, some of their functionality is still being provided. It is quite hard to find those features though, as they are spread across multiple NuGet packages and there is very little documentation at this stage. Issues on github are the best source of information, but there has been a high churn of APIs in this area and a lot of those discussions and APIs are out-of-date. If you have been hunting around for these features then I hope the code samples here will at least provide you with a good starting point and some clues as to where to find related features.

Replacing AppDomain Unload event

In .Net classic, it could be quite useful to run code in the AppDomain Unload event, especially if you wanted to perform some actions after all of your tests had completed.

System.AppDomain.CurrentDomain.DomainUnload += (sender, e) => {
    InvokeBatchProcessors();
};

There are no AppDomains in .Net Core. Instead, we can use the AssemblyLoadContext, which is part of the System.Runtime.Loader library:

System.Runtime.Loader.AssemblyLoadContext.Default.Unloading += context => InvokeBatchProcessors();

At the time of writing, the current version of System.Runtime.Loader package is 4.0, which you include in your project.json with this entry.

"System.Runtime.Loader": "4.0.0",

Replacing AppDomain.GetAssemblies

In .Net classic, you could get all of the referenced assemblies from AppDomain.

AppDomain.CurrentDomain.GetAssemblies();

I really struggled to figure out how to do this in .Net Core. Up until RC1, you were able to use the LibraryManager from the Microsoft.Extensions.PlatformAbstractions package to do it, but that functionality was either removed or moved somewhere else for RC2.

return libraryManager.GetReferencingLibraries("Specify")
    .SelectMany(a => a.Assemblies)
    .Select(Assembly.Load);

One way to do it now, is with the DependencyContext from the Microsoft.Extensions.DependencyModel package. You have to load each assembly and use the new AssemblyName class.

public static IEnumerable<Assembly> GetReferencingAssemblies(string assemblyName)
{
    var assemblies = new List<Assembly>();
    var dependencies = DependencyContext.Default.RuntimeLibraries;
    foreach (var library in dependencies)
    {
        if (IsCandidateLibrary(library, assemblyName))
        {
            var assembly = Assembly.Load(new AssemblyName(library.Name));
            assemblies.Add(assembly);
        }
    }
    return assemblies;
}

private static bool IsCandidateLibrary(RuntimeLibrary library, assemblyName)
{
    return library.Name == (assemblyName)
        || library.Dependencies.Any(d => d.Name.StartsWith(assemblyName));
}

The DependencyContext.Default has two properties, RuntimeLibraries and CompileLibraries, which both appear to provide the same list of libraries. I'm sure there is a difference between them but at this stage I am not sure what that difference is.

The current version of Microsoft.Extensions.DependencyModel is 1.0:

"Microsoft.Extensions.DependencyModel": "1.0.0"

Get All Types from AppDomain

If you were getting all the assemblies from the AppDomain, chances are you were wanting to retrieve the types in those assemblies matching a certain query. Using an AppDomain, you could do that like this:

return AppDomain.CurrentDomain
    .GetAssemblies()
    .SelectMany(assembly => assembly.GetExportedTypes());

It is pretty similar with .Net Core. Again, using the Microsoft.Extensions.DependencyModel library and the GetReferencingAssemblies method from the previous example:

return GetReferencingLibraries("Specify")
    .SelectMany(assembly => assembly.ExportedTypes);

Assembly now has an ExportedTypes method instead of GetExportedTypes.

Creating a Polyfill

As I described in my previous post, when porting your code to .Net Core you might like to include a polyfill for missing functionality, so that your code can interact with both implementations seamlessly. A polyfill for AppDomain.CurrentDomain.GetAssemblies would look like this:

public class AppDomain
{
    public static AppDomain CurrentDomain { get; private set; }

    static AppDomain()
    {
        CurrentDomain = new AppDomain();
    }

    public Assembly[] GetAssemblies()
    {
        var assemblies = new List<Assembly>();
        var dependencies = DependencyContext.Default.RuntimeLibraries;
        foreach (var library in dependencies)
        {
            if (IsCandidateCompilationLibrary(library))
            {
                var assembly = Assembly.Load(new AssemblyName(library.Name));
                assemblies.Add(assembly);
            }
        }
        return assemblies.ToArray();
    }

    private static bool IsCandidateCompilationLibrary(RuntimeLibrary compilationLibrary)
    {
        return compilationLibrary.Name == ("Specify")
            || compilationLibrary.Dependencies.Any(d => d.Name.StartsWith("Specify"));
    }
}

Summary

While AppDomains have been discontinued, for the time being at least, some of their functionality is still being provided. It is quite hard to find those features as they are spread across multiple NuGet packages and there is very little documentation at this stage. Issues on github are the best source of information, but there has been a high churn of APIs in this area and a lot of those discussions and APIs are out-of-date. If you have been hunting around for these features then I hope the code samples here will at least provide you with a good starting point and some clues as to where to find related features.

Porting a .Net Framework Library to .Net Core

2016-07-04T07:00:00Z

I have recently been involved with porting a couple of open source frameworks to .Net Core. It's a brave new world, with lots of new things to discover and learn. In this post I am going to outline the process I've followed to convert my code and a few of the things I've learned along the way. Hopefully, this post will shed some light on the process if you are looking to port your .Net Framework code to .Net Core. Special thanks to Jake Ginnivan who, as always, was a font of knowledge on all things programming during the porting exercises!

Run the .Net Portability Analyzer

Before you even attempt to port your library, you should run the .Net Portability Analyzer on your existing project. This is available as a console application or a Visual Studio plugin. You can access the Visual Studio plugin by right clicking on the project and selecting Analyze -> Analyze Assembly Portability.

This will produce a report that provides two useful pieces of information:

High-level summary: The summary gives you a percentage for each of your assemblies, telling you how much of your framework usage is portable to .NET Core.
List of non-portable APIs: It provides a table that lists all the usages of APIs that aren’t portable. Most usefully, it also includes a list of recommended changes.

Run I Can Has .Net Core

Another useful analysis tool is the I Can Has .Net Core website. Just upload your project's packages.config, project.json or paket.dependencies files for analysis and it will build a visualisation of the packages and whether .NET Standard versions are available on nuget.org.

Create a new .Net Core class library project

The way to "upgrade" a .Net framework project is actually to create a new .Net Core class library and copy the old C# files into it. Assuming you want it to have the same name as the old project, and be in the same folder, you should remove the existing project and rename its folder on the file system so that the new project can be saved to the original location.

Add a global.json file

You will need to add a global.json file to the solution, which is used to configure the solution as a whole. It includes just two sections, projects and sdk by default.

{
  "projects": [ "app", "tests" ],
    "sdk": { "version": "1.0.0-preview2-003121" }
}

The projects property designates which folders contain source code for the solution. The sdk property specifies the version of the DNX (.Net Execution Environment) that Visual Studio will use when opening the solution. (I think DNX might no longer be the correct terminology. .Net Core has been an ever moving target).

Add target frameworks to project.json file

The frameworks node in project.json specifies the framework versions that the project should be compiled against. In this example, the library will support .Net 4 (net40) and .Net Standard 1.5 (netstandard1.5). Because .Net Core has been decomposed into many modules, this allows you to specify the additional NuGet package dependencies that .Net Core needs (shown in the netstandard1.5 node below).

{
  "version": "1.0.0-*", 
  "dependencies": {
    "LibLog": "4.2.5",
    "TestStack.BDDfy": "4.3.0"
  },
    "frameworks": {
        "net40": {
          "dependencies": {

          },
            "frameworkAssemblies": {
                "System.Runtime.Serialization": "4.0.0.0",
                "System.Xml": "4.0.0.0"
            }
        },
        "netstandard1.5": {
            "imports": "dnxcore50",
            "buildOptions": {
              "define": [
                "LIBLOG_PORTABLE",
                "NETSTANDARD1_5"
              ]
            },
          "dependencies": {
            "NETStandard.Library": "1.6.0",
            "Microsoft.CSharp": "4.0.1",
            "System.Dynamic.Runtime": "4.0.11"
          }
      }
    }
}

Fixing missing references for .Net Core

When you first build the project, you will most likely get a lot of missing reference exceptions for the .Net Standard target framework (see image below). Note that the project is specified as [ProjectName].NetStandard, Version 1.5.

This is quite easy to resolve if this functionality has been ported to one of the many new .Net Core packages. The Reverse Package Search website is a great tool for finding NuGet packages that contain different types. For example, searching for the missing DynamicAttribute from the above error returns the System.Dynamic.Runtime NuGet package. This just needs to be added to the list of dependencies under the netstandard node to resolve the missing reference exception.

GetTypeInfo

One of the most common issues is that a lot of the old System.Type reflection functionality has moved to TypeInfo in .Net Core, which you can access through the GetTypeInfo extension method on Type.

So, instead of

var members = obj.GetType().GetMembers();

you would now use:

using System.Reflection;
var members = obj.GetType().GetTypeInfo().GetMembers();

I am sure that more elegant solutions will come out in time, but for now the way I am handling these differences is with compiler directives. What I have found effective is to create a TypeExtensions class with extension methods on Type. There I replace the various Type properties with methods of the same name, with separate implementations of each method for each supported framework. This, at least, constrains the compiler directives to one place, rather than doing it for every method, and leaves the production code free of compiler directives.

#if NET40
    public static class TypeExtensions
    {
        public static Assembly Assembly(this Type type)
        {
            return type.Assembly;
        }

        public static bool IsValueType(this Type type)
        {
            return type.IsValueType;
        }
    }
#else
    using System.Linq;
    public static class TypeExtensions
    {
        public static Assembly Assembly(this Type type)
        {
            return type.GetTypeInfo().Assembly;   
        }

        public static bool IsValueType(this Type type)
        {
            return type.GetTypeInfo().IsValueType;
        }
    }
#endif

So, instead of calling the Reflection property, my code now calls my extension method with the same name. For example:

// type.IsValueType;
type.IsValueType();

Compiler directives or rewrite code

It is not ideal to have too many compiler directives in your code. When a feature you were using in the old framework has not been ported to .Net Core you have a choice to make

Write a new solution for .Net Core and switch between the old and new implementations with compiler directives, or
Replace the original implementation with a new one that works for both frameworks

For example, I had some JSON serialization functionality that relied on the JavaScriptSerializer in the System.Web library. This serializer has not been ported to .Net Core, so the short term fix - to get things working - was to use compiler directives to keep the existing soluiton for .Net 4 and provide a new solution for .Net Core.

#if NET40
    using System.Web.Script.Serialization;  
    public class JsonSerializer : ISerializer
    {
        public string Serialize(object obj)
        {
            var serializer = new JavaScriptSerializer();
            string json = serializer.Serialize(obj);

            return new JsonFormatter(json).Format();
        }
    }
#else
    using Newtonsoft.Json;
    public class JsonSerializer : ISerializer
    {
        public string Serialize(object obj)
        {
            return JsonConvert.SerializeObject(obj, Formatting.Indented,
                new JsonSerializerSettings
                {
                    NullValueHandling = NullValueHandling.Ignore,
                    ReferenceLoopHandling = ReferenceLoopHandling.Ignore
                });
        }
    }
#endif

As more things get ported to .Net Core though, ideally I would hope to remove compiler directives and have a single solution that works for both frameworks, because it really is not ideal to maintain multiple implementations of lots of functionality throughout a codebase.

Thankfully, the DataContractJsonSerializer has been ported to the System.Runtime.Serialization.Json NuGet package, so I can actually have a single solution that is supported by both frameworks and remove the compiler directives.

using System.Runtime.Serialization.Json;
public class JsonSerializer : ISerializer
{
    public string Serialize(object obj)
    {
        var serializer = new DataContractJsonSerializer(obj.GetType());
        string json;
        using (var stream = new MemoryStream())
        {
            serializer.WriteObject(stream, obj);
            json = Encoding.UTF8.GetString(stream.ToArray());
        }

        return new JsonFormatter(json).Format();
    }
}

Why didn't I just use Json.Net or ServiceStack.Text to serialize Json? Well, I would if I was building an application, but for a NuGet library I don't want to add a NuGet dependency just for one class of functionality. That might be old world thinking though, given how much of the .Net Framework is now provided as NuGet packages. I may just change my thinking on that but, for now, I still see a distinction between third party packages and .Net packages.

Backwards-compatible Polyfills

Credit to Jake Ginnivan for this solution. It is actually pretty easy to satisfy the compiler by providing polyfills, or shims, for types that have not been ported to .Net Core.

For example, Serialization has not been ported, but you might have classes with the Serializable attribute on them. Providing an empty SerializableAttribute class in the System.Runtime.Serialization namespace will satisfy the compiler for your .Net Core code.

#if !NET40
namespace System.Runtime.Serialization
{
    public class SerializableAttribute : Attribute
    {
    }
}
#endif

Another example I have come across is a polyfill for AppDomain.CurrentDomain, now that AppDomains are no longer supported in .Net Core.

private sealed class AppDomain
{
    public static AppDomain CurrentDomain { get; private set; }

    static AppDomain()
    {
        CurrentDomain = new AppDomain();
    }

    public List<Assembly> GetAssemblies()
    {
        ... // .Net Core functionality here
    }
}

Summary

There are a lot of exciting new things to learn with .Net Core. Porting your existing code to the framework is a little bit of work - but not too much. The process is quite straightforward with predictable steps, most of which I've hopefully communicated here. The .Net Portability Analyzer is a huge help in enabling you to plan out the conversion beforehand, providing you with a list of issues and - most helpfully - even the solutions to most of the issues. The main area of concern is to provide new solutions for areas of the code that rely on parts of the .Net Framework that have not been ported. Thankfully, this seems to be a reasonably small surface area though, of course, it will depend on each application.

GitHub CVs / Resumes

2016-06-02T07:00:00Z

I just discovered that Github can automatically generate a CV/resume for its users based on the public information in their GitHub account. You have to opt-in by going to their GitHub project page and starring the project. Check out mine at http://resume.github.com/?mwhelan. What a clever idea!

Review of Pluralsight's Become a Full-stack .Net Developer

2016-05-30T09:00:00Z

This weekend was a long weekend in the UK, and my wife was away, so I took the opportunity to work through Mosh Hamedani's comprehensive 3 part course on Pluralsight, titled Become a Full-stack .Net Developer. The three part series aims to take you from a junior .Net developer through to a senior .Net developer by building an ASP.Net MVC 5 application with Entity Framework 6. I really enjoyed the course and thought I would provide a review of it.

The series is a whopping 14 hours in total, which is really, really long by Pluralsight standards. I would really recommend watching it though and will probably make it suggested watching for my dev teams.

I did intend to build out the whole thing while I watched but I abandoned that as it would have taken too long (though I would recommend doing that if you are a little less experienced). I revved up the speed to double and watched it like a movie. That's still 7 hours of watching, but well worth it.

According to Mosh, the series is aimed at the following audiences

Part 1 => junior developer
Part 2 => moving from junior developer to intermediate developer
Part 3 => moving from intermediate developer to senior developer

Hearing that, a lot of experienced devs might move right along, but I'd encourage you to look a bit deeper. While the content is geared towards ASP.Net MVC 5 and Entity Framework 6, the most valuable takeaway is the approach of a senior developer.

What impressed me the most was Mosh's discipline. He did not let himself get distracted by going off to google to research better solutions, but consistently stuck to the task at hand, OK with doing it a bit dirty at first, confident that with an iterative approach to development he would quickly circle back and remove any technical debt. I can be far less disciplined and find it so easy to get sidetracked on to some research or other yak shaving activity. There's so much to be said for completing the task!

My favourite part was the third and final part, which gets into architecture and automated testing and such, two topics close to my heart. But the first two are really good value as well. In fact, if Mosh didn't tell you they were aimed at the 3 levels you wouldn't know the difference. It's just that he starts off doing ugly things like newing up the DbContext directly in the controller so that he doesn't distract you with too many concepts at once. But slowly but surely, he refactors things until eventually you have a pretty clean architecture, with repositories/unit of work, and programming to interfaces that are injected with your IoC container.

The style of the course is similar to pairing with an experienced developer who is just commentating on what he is doing and why. He shows a number of productivity tools, such as ReSharper, Web Essentials and the Productivity Power Tools. In particular, he shows a number of ReSharper shortcuts. Unfortunately, he uses the older IntelliJ shortcuts and I use the Visual Studio ones, but it was no problem to look up their Visual Studio counterparts on their website.

You can view the courses here.

You can currently get 6 months of Pluralsight for free if you sign up for an MSDN Dev Essentials subscription.

I think Mosh is a really talented teacher and his style and focus on quality is quite distinctive from other teachers. I can also recommend some of his Udemy courses that I've done. You can also find him on his youtube channel.