DEV Community: Simon Reynolds

Announcing EFCore.FSharp

Simon Reynolds — Sun, 21 Mar 2021 15:05:49 +0000

Today marks the first alpha release of F# support for Entity Framework Core, allowing for direct usage of EF Core from your F# projects with support for EF Core 5.0.3

It contains support for migrations and reverse-engineering, allowing you to map tables to F# records and take advantage of F# idioms such as option to represent nullable columns. At the moment though, this does not work for primary or foreign keys, just plain columns (GitHub issue).

To take it for a test drive, grab the NuGet package from https://www.nuget.org/packages/EntityFrameworkCore.FSharp

Bear in mind that it is an alpha release so please log any issues on the GitHub repo.

Currently it has support for relatively simple schemas, it does not support many-types-per-table relationships yet but that is on the to-do list.

Although it does support option columns it does not yet support types such as discriminated unions.

Installation

All the usual ways of grabbing a NuGet package...

Install-Package EntityFramworkCore.FSharp

dotnet add package EntityFramworkCore.FSharp

paket install EntityFramworkCore.FSharp

Usage

When it is installed, you will need to register it for dotnet ef to pick it up. Simply add the following code to your project. It will be detected at compile time, no need to call it from a Startup class

module DesignTimeServices

open Microsoft.Extensions.DependencyInjection
open Microsoft.EntityFrameworkCore.Design
open EntityFrameworkCore.FSharp

type DesignTimeServices() =
    interface IDesignTimeServices with 
        member __.ConfigureDesignTimeServices(serviceCollection: IServiceCollection) = 
            let fSharpServices = EFCoreFSharpServices.Default
            fSharpServices.ConfigureDesignTimeServices serviceCollection
            ()

Migrations

Code first databases are supported, a working example of creating a basic MVC application in F# with user authentication is available at https://github.com/simon-reynolds/EFCore.FSharp.MvcAuth

One thing to remember is that record types have to have the [<CliMutable>] attribute specified so that they can be created correctly by Entity Framework.

After running dotnet ef migration add you will need to add the created files to your your project. The migration files are generated sequentially so you can add a single glob reference to your fsproj file to add them all at once

<Compile Include="Migrations/*.fs" />

There is an issue to track this to try find an automated solution. As always, any help or suggestions are welcome.

Scaffolding

When scaffolding a model from an existing database, we can specify how we want the generated code to be created in our DesignTimeServices type above.

We can create types as either record types or classes similar to how they behave in C#

For instance, given a blog post type with an Id, Title and Content, it can generated as either example below.

// Record type
type BlogPost = {
    Id : int
    Title: string
    Content: string
}

// Class type
type BlogPost() =

    [<DefaultValue>] val mutable private _Id : int
    member this.Id with get() = this._Id and set v = this._Id <- v

    [<DefaultValue>] val mutable private _Title : string
    member this.Title with get() = this._Title and set v = this._Title <- v

    [<DefaultValue>] val mutable private _Content : string
    member this.Content with get() = this._Content and set v = this._Content <- v

Similarly, optional columns can either be rendered as Nullable<'a> or as 'a option. The default configuration will create record types with nullable columns specified as option types.

These are done by defining our scaffold options and passing them into the DesignTimeServices, e.g.

module DesignTimeServices =

    open Microsoft.Extensions.DependencyInjection
    open Microsoft.EntityFrameworkCore.Design
    open EntityFrameworkCore.FSharp

    type DesignTimeServices() =
        interface IDesignTimeServices with
            member __.ConfigureDesignTimeServices(serviceCollection: IServiceCollection) =

                // The default behaviour can be specified by calling
                let fSharpServices = EFCoreFSharpServices.Default

                // Or we can define a ScaffoldOptions use that instead
                let scaffoldOptions =
                    ScaffoldOptions (
                        ScaffoldTypesAs = ScaffoldTypesAs.ClassType,
                        ScaffoldNullableColumnsAs = ScaffoldNullableColumnsAs.NullableTypes)

                let fSharpServices = EFCoreFSharpServices.WithScaffoldOptions scaffoldOptions

                fSharpServices.ConfigureDesignTimeServices serviceCollection
                ()

More details can be found in our project documentation here.

Option types

It has basic support for option types, including an OptionConverter for mapping nullable columns to options. When building a code first database simply include the following at the end of OnModelCreating

type MyContext (options) = 
    inherit DbContext (options)

    override this.OnModelCreating mb =
        (* Define entities here *)

        modelBuilder.RegisterOptionTypes()

Other issues

I'm sure there are. Please report any issues you discover and help us improve F# support for Entity Framework Core!

Azure Storage Explorer and Multi-Factor Authentication

Simon Reynolds — Wed, 30 Sep 2020 11:49:17 +0000

We use multi-factor authentication for all azure accounts and access at $EMPLOYER, because of course we do (and you should too). Being hacked isn't fun at the best of times, having your azure account being hacked is a quick route to a whole (and expensive) world of pain.

This is great and provides a lot of extra security. But it's also a massive pain in the ass when you have multiple subscriptions and need to do the whole username, password, MFA challenge on every subscription when you open Azure Storage Explorer.

To get around this, click Edit -> Settings and select the following option:

Microsoft Authentication Library (Preview)

Then restart Azure Storage Explorer and authenticate one last time. Now your subscriptions will remain signed in across restarts and when you open Storage Explorer you can get straight to what you want to do instead of yet another round of approving multiple sign in requests.

WTF is a Computation Expression...

Simon Reynolds — Mon, 20 Jul 2020 08:00:00 +0000

...and why should I care?

Every time computation expressions in F# are discussed it's only a matter of time before the dreaded M-word is mentioned. So let's get it out of the way early....

Monad

Right, that's that done and let's not mention it again. Suffice to say, they're an interesting concept with no equivalent in C# and no necromancy is required to use or make them.

If you've done any async work in F# or anything involving sequences then odds are you've already used a computation expression (CE).

let mySequence =
    seq {
        "First Item"
        "Second Item"
    }

let myAsyncThing =
    async {
        let! result = DoTheAsyncThing
        return result
    }

The F# compiler has no built-in tricks or optimisations for these, they're just plain computation expressions, just like you can write too!

Every computation expression needs a backing builder class, usually named after the computation, so async would have a builder of type AsyncBuilder. All it has to do to be used as a CE is implement certain methods, which map to particular keywords inside a CE.

Method	Typical signature(s)	Description
Bind	`M<'T> * ('T -> M<'U>) -> M<'U>`	Called for `let!` and `do!` in computation expressions.
Delay	`(unit -> M<'T>) -> M<'T>`	Wraps a computation expression as a function.
Return	`'T -> M<'T>`	Called for `return` in computation expressions.
ReturnFrom	`M<'T> -> M<'T>`	Called for `return!` in computation expressions.
Run	`M<'T> -> M<'T>` or `M<'T> -> 'T`	Executes a computation expression.
Combine	`M<'T> * M<'T> -> M<'T>` or `M<unit> * M<'T> -> M<'T>`	Called for sequencing in computation expressions.
For	`seq<'T> * ('T -> M<'U>) -> M<'U>` or `seq<'T> * ('T -> M<'U>) -> seq<M<'U>>`	Called for `for...do` expressions in computation expressions.
TryFinally	`M<'T> * (unit -> unit) -> M<'T>`	Called for `try...finally` expressions in computation expressions.
TryWith	`M<'T> * (exn -> M<'T>) -> M<'T>`	Called for `try...with` expressions in computation expressions.
Using	`'T * ('T -> M<'U>) -> M<'U> when 'T :> IDisposable`	Called for `use` bindings in computation expressions.
While	`(unit -> bool) * M<'T> -> M<'T>`	Called for `while...do` expressions in computation expressions.
Yield	`'T -> M<'T>`	Called for `yield` expressions in computation expressions.
YieldFrom	`M<'T> -> M<'T>`	Called for `yield!` expressions in computation expressions.
Zero	`unit -> M<'T>`	Called for empty `else` branches of `if...then` expressions in computation expressions.
Quote	`Quotations.Expr<'T> -> Quotations.Expr<'T>`	Indicates that the computation expression is passed to the Run member as a quotation. It translates all instances of a computation into a quotation.

Now that all looks complicated so let's take a quick look at what advantages a CE gives us over writing plain code.

Let's consider an example where we need to pass an item through several validation checks

let itemToValidate = SomeThingThatNeedsValidating()

// Each validation methhod has signature Item -> Result<Item, Error>

let firstValidation = firstValidationCheck itemToValidate

let secondValidation =
    match firstValidation with
    | Error e -> e
    | Ok item -> secondValidationCheck item

let thirdValidation =
    match secondValidation with
    | Error e -> e
    | Ok item -> thirdValidationCheck item

You probably look at that and think there must be a better way to write that. And you'd be right, this is a great example where we can use a computation expression.

To build it, let's look at the Result type and see if it has anything that can help us.

There is already a Result.bind that does the same as the match statements above, so let's use that instead of reinventing the wheel.

type ResultBuilder() =

    // This can be used in a CE via the let! keyword
    // Result<'a,'b> * ('a -> Result<'c,'d>) -> Result<'c,'d>
    member __.Bind(r, f) = Result.bind f r

    // This can be used in a CE via the return keyword
    // 'a -> Result<'a, 'b>
    member __.Return(x) = Ok x

// This exposes the builder type as a computation expression
// It's what allows to use it like below...
let result = ResultBuilder()

Short, sharp and to the point, right? But now we can express the validation checks above like this...

let itemToValidate = SomeThingThatNeedsValidating()

let validatedItem =
    result { // result here is the created instance of ResultBuilder from above
        let! firstCheck = firstValidationCheck itemToValidate
        let! secondCheck = secondValidationCheck firstCheck
        let! thirdCheck = thirdValidationCheck secondCheck
        return thirdCheck
    }

The beauty of this approach is that the let! keyword will only bind the successful validation and allow the CE to continue evaluating. If an error is returned from any of the validation checks then the entire CE will short circuit and return that error immediately.

Congratulations, you now have a basic working CE of your very own! But a lot of that code looks like we shouldn't need it. Why assign each intermediate result to a variable along the way, surely we should just be able to pipe each step in to the next, right?

Let's add two further items to where we create our ResultBuilder

// F# allows us to define our own operators
// By convention, >>= usually refers to a bind method
let (>>=) result binder = Result.bind binder result

type ResultBuilder() =

    // This can be used in a CE via the let! keyword
    // Result<'a,'b> * ('a -> Result<'c,'d>) -> Result<'c,'d>
    member __.Bind(r, f) = Result.bind f r

    // This can be used in a CE via the return keyword
    // 'a -> Result<'a, 'b>
    member __.Return(x) = Ok x

    // This can be used in a CE via the return! keyword
    // Result<'a, 'b> -> Result<'a, 'b>
    member __.ReturnFrom x = x

let result = ResultBuilder()

Now we can chain together our validation checks and it becomes a lot easier to be able to add new checks, compose smaller ones together, or reorder them without having to rename every variable along the way.

let itemToValidate = SomeThingThatNeedsValidating()

let validatedItem =
    result {
        return!
            firstValidationCheck itemToValidate
            >>= secondValidationCheck
            >>= thirdValidationCheck
    }

Now if we found we needed an extra check that should be between secondValidationCheck and thirdValidationCheck, it is as simple as adding it in.

Hopefully this has helped to show you the power of a computation expression and that they aren't as scary as they first seemed. Of course this was a relatively simple example but from here you can see how they can be extended with additional functionality and even custom keywords that can be used to create miniature programming languages to solve problems. More to come on that front....

Hosting multiple web applications in Docker

Simon Reynolds — Tue, 07 Jul 2020 13:00:00 +0000

I've written before about developing software in Docker containers and while that has been a step forward for development and being able to isolate development environments, the strength of Docker has always been in running applications without having to worry about requirements or dependencies.

How it all began...

For managing clusters of applications we have plenty of options, Kubernetes, Docker Swarm, OpenStack and of course Docker Compose.

Options like Kubernetes are indispensable when operating at scale, with dozens, hundreds or even thousands of instances of multiple microservices all working together to provide a full application.

But when it comes to something like hosting a personal blog like this one then it can be overkill. Something simpler like Docker Compose will do just fine.

version: '3.1'

services:
  ghost:
    container_name: ghost
    image: ghost:alpine
    restart: always
    ports:
      - 127.0.0.1:2368:2368
    volumes:
      - ./content:/var/lib/ghost/content
      - ./config.production.json:/var/lib/ghost/config.production.json

This is a relatively simple example of a docker-compose.yml file but it shows the important details, we specify our image, it's set to restart automatically in case of a crash or failure and mounts some files from the native file system and forwards to a port on the server itself.

This is where we can set up a reverse proxy in nginx, but why install it when nginx is available as a docker image?

Particularly when we have the chance to use this amazing piece of work?

evertramos / nginx-proxy-automation

Automated docker nginx proxy integrated with letsencrypt.

It sits between one or more docker containers and the outside world, forwarding requests and also taking care of SSL certificates using LetsEncrypt.

To host our ghost blog behind it all we need to do is expand our docker-compose file and restart that container. The nginx proxy will detect it based on the extra environment variables and handle all proxy reversing and add your new SSL certificates.

version: '3.1'

services:
  ghost:
    container_name: ghost
    image: ghost:alpine
    restart: always
    ports:
      - 127.0.0.1:2368:2368
    volumes:
      - ./content:/var/lib/ghost/content
      - ./config.production.json:/var/lib/ghost/config.production.json
    environment:
      # Note how VIRTUAL_HOST and LETSENCRYPT_HOST allow for multiple domains
      - VIRTUAL_HOST=simonreynolds.ie,www.simonreynolds.ie
      - LETSENCRYPT_HOST=simonreynolds.ie,www.simonreynolds.ie
      - LETSENCRYPT_EMAIL=REDACTED@example.com
      - MAIN_DOMAIN=simonreynolds.ie
      - VIRTUAL_PORT=2368

networks:
  default:
      external:
        name: webproxy

I took the extra step of creating the webproxy network myself so I can host multiple sites across different domains from just one server.

This makes spinning up small sites for testing ideas incredibly easy and fully automates SSL certificates so I never have to worry about expired certificates again!

SSRS Access woes

Simon Reynolds — Fri, 03 Jul 2020 08:00:00 +0000

I'm writing this up for two reasons, one is that I can find this again next time it happens. The second is simple but important, we all make mistakes and at times they can seem pretty obvious in retrospect. But it's important to share the stories of our failures as well as our successes.

We all do both but when we tend to only talk about our successes it can encourage feelings of impostor syndrome in others. So let's talk more about our mistakes. And on that note.....

Picture the scene. It's been a long day but I'm about to release to production with some changes including moving our trusty old SSRS server.

A final double check, I can run reports fine in testing, I've updated firewall rules, I've changed the report server url in all the config files.... it all looks good!

Then I deploy, everything is looking good, and I go to run a report....

The traditional mid-deployment cry of a programmer

The moral of this story is simple:

CHECK YOUR DAMN CREDENTIALS

Not all environments are using the same credentials and when I set them up in Site Settings, I forgot that I also need to click here too....

The simple cause of many problems

In Folder Settings, click on New Role Assignment and add users here too! Give them the required permissions, e.g. Content Manager, and now they have permission to view and run reports. Voilà, suddenly all is as it should be and a full blown crisis has been averted.

FsCheck: An introduction

Simon Reynolds — Tue, 30 Jun 2020 08:00:00 +0000

We've all heard of unit testing and some of us have even been known to practice it. It has a simple premise

Have a method or some other "unit" of code you want to test
Pass in some contrived test data
Compare the result to what you would expect it to be

This is essentially example based testing. All we can guarantee with it is that the output is as expected for the given input. That may be a single case or a handful of test cases.

If we were to imagine we had a requirement for a method that would reverse any given string of text then we could have a particularly obtuse developer who only wants to implement exactly what is in the requirement, no more and no less.

If the requirement states

For example, a given string "abcdef" would be reversed to "fedcba"...

then it's possible that our developer may write something like this.

test "String reverses correctly" {
    let expected = "fedcba"
    let input = "abcdef"

    Expect.equal (reverse input) expected "Should be equal"
}

This all looks straightforward enough until we look at the implementation of reverse

let reverse (input:string) =
    "fdecba"

This is clearly a contrived example but we can see how one test is not exhaustive. But what's the alternative? We clearly can't create a list of every possible string of text. Especially when we consider the amount of whitespace and non-printable characters.

We need random input, this is where we need property based testing. We can consider the properties of a method that would reverse a string.

The characters that make up the original string will all be in the reversed string, but in the opposite order
So if we count each character in both, we should never have a character that only appears once
Both strings should be the same length
If we join the two strings into a new string, the same character should be repeated in the middle
Reversing a string twice should give us the original again

Reversing the string again is a useful test but by itself does not prove that the reverse method is complete. After all if it just returned the string unchanged then the string would be the same after two calls to reverse.

A more useful test would be to compare the reversed string and iterate backwards through each character. Each character should match if we were to iterate forwards through the original string.

Let's use a property based testing framework called FsCheck. It allows us to test the assumptions in our methods and find edge cases we never even considered.

let reverse (input:string) =
    if isNull input then
        null
    else
        let charArray = input.ToCharArray() |> Seq.rev |> Seq.toArray
        String(charArray)

let properties =
    testList "ReversePropertyTests" [

        testProperty "Char at index[length-n] of reversed string equals index[n] of original" <|
            fun (input:string) ->
                let reversed = reverse input

                if isNull input then
                    reversed = input
                else
                    // Account for zero-based index
                    let reversedLength = reversed.Length - 1
                    let reversedAsArray = reversed.ToCharArray()
                    input
                        |> Seq.mapi(fun i c -> c = reversedAsArray.[reversedLength - i])
                        |> Seq.forall id

       // This will likely fail, can you see why?
       testProperty "Reversed string should have same length as original" <|
            fun (input:string) ->
                let reversed = reverse input
                reversed.Length = input.Length

       // Think about what other testProperty could be defined here

    ]

This way, we are not testing any individual input. Instead FsCheck will, by default, run the test 100 times using progressively more complicated strings that include whitespace, line breaks, unprintable characters etc.

If a test fails, the framework will then restrict the inputs it generates based on the failing tests to try identify ranges of failure. When a failure is encountered it will attempt to reduce the failure to the minimum changes from passing tests required for it to fail.

In practice this means that if we were testing a method with DateTime parameters, it might be able to show us that there is an error in the method when dealing with dates in specific ranges or that only occur before or after particular dates.

It is also very adaptable, we can create custom data generators, allowing us to create random data within ranges or of specific types. For instance, you may want to create random email addresses or some other constrained type.

These are some of the properties we can test using a library like FsCheck. Obviously in this example the first property above is enough to define the method entirely but in more complex scenarios, it can be better to have a number of tests that each check an individual property of the scenario. An example of this is Mark Seemann's excellent Introduction to Property Based Testing on Pluralsight which utilises the Diamond Kata as a demonstration.

FsCheck is a .NET library so although it is written in F# and primarily with the F# ecosystem in mind it can be used just as easily in C# or VB.NET. It uses a PropertyAttribute or any custom attribute which inherits from it. Although the examples here are written using Expecto and its FsCheck plugin, there are also plugins for xUnit and NUnit.

Property based testing is a different method of thinking about your tests but something well worth considering, especially for those areas of your codebase that seem to always have more edge cases every time you look at them. By making you stop and think about the more generalised properties of what the method should be doing it flushes those edge cases out into the light where they can be found.

MiniScaffold, setting up a new F# project the easy way

Simon Reynolds — Fri, 26 Jun 2020 08:00:00 +0000

Setting up a new project can be a pain. Especially if you want to split it into separate folders for clarity. You might want a src folder for the project itself, a test folder for the unit and integration tests, a docs folder for documentation. You are writing documentation for your work, right?

Of course I always do too

If you're writing in F# you've probably long ago moved from NuGet to Paket, but the standard .NET templates still use NuGet so that has to be migrated. There's build scripts to write too. It could be an hour or more of work before you start working on the code you actually wanted to write.

Enter MiniScaffold, a dotnet template that is for creating and publishing applications (supporting .NET Core 3.1) and libraries (supporting both .NETStandard 2.1 and .NET Framework 4.6.1

It's designed and built to take care of the humdrum for you, it gives you

a clean and well separated folder structure
a matching .gitignore file
an .editorconfig file tweaked for F# development
configures CI builds on Appveyor (for Windows) and TravisCI (for Linux and macOS)
fully configured build scripts using FAKE
integrated package management with Paket
integrated unit testing (Expecto) and code coverage reports (AltCover/ReportGenerator)
automatic code formatting with Fantomas

And that's just to get started, also included is a file named CHANGELOG.md. All you have to do is keep it updated with your notable changes, even reference the associated pull requests for those changes.

The generated build scripts include a Release action that will parse the CHANGELOG.md file, create a tag in GitHub with the version number specified, update any pull requests mentioned with the version number, publish a GitHub release for the version and even include any build artifacts in the dist folder! Doing all that is as easy as typing seven extra characters

# Development build
./build.sh

# Release build
./build.sh Release

It's certainly an opiniated template, if you really wanted to go with a different test library for example, you'd have enough repeated work changing it each time that it would probably be better to fork the github project and customise it yourself. But I'd recommend trying it out first, it becomes second nature and is now my go to template for all F# projects!

To get started, install the template

dotnet new -i "MiniScaffold::*"

Then go with

# I'm building a library
dotnet new mini-scaffold -n MyCoolNewLib --githubUsername MyGithubUsername

# I'm building an application
dotnet new mini-scaffold -n MyCoolNewApp --githubUsername MyGithubUsername -ou console

The author of this template, Jimmy Byrd, has clearly put an incredible amount of effort into this and it is a great example of how creating a template (or any project) to simplify some repetitive task is always worth sharing with the community.

Yet more "fun" with time zones in .NET

Simon Reynolds — Tue, 23 Jun 2020 08:00:00 +0000

It is a truth universally acknowledged, that a .NET project in possession of multiple time zones, must be in want of Noda Time. Sometimes though, we have an existing project where it's just not reasonable to move everything over and we need a way to display a DateTime in a time zone that may not necessarily be the local time zone.

While .NET does include such types as DateTimeOffset, an offset for UTC is not the same as a timezone. Time zones can and do change, including daylight saving changes. An offset from UTC does not reflect that and can be shared across many time zones.

For instance, if we created a DateTimeOffset with a UTC offset of +01:00, that could be Paris in winter (Central European Time), Dublin in summer (Irish Standard Time) or Lagos in Nigeria (West Africa Time) at any time of year since daylight saving is not observed there.

Suppose instead that we have a system where the DateTime has been saved as UTC and we now want to display it as a local time zone. If we have a given string tzId representing our time zone then we can do the following...

DateTime utc = DateTime.UtcNow;

DateTime local =
   TimeZoneInfo.ConvertTimeFromUtc(utc,
       TimeZoneInfo.FindSystemTimeZoneById(tzId));

If you're running .NET Framework then you're restricted to Windows and you can use the Windows time zones defined in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\.

If you're running .NET Core then it gets a little more complicated.

On Windows hosts then it still uses the registry entries above, where for example Dublin, Ireland is represented as "GMT Standard Time". On Linux and macOS it uses the tzdata format of "Europe/Dublin".

This does make things awkward at the moment, particularly in Azure functions where you don't know what platform your code is going to be running on.

If you know the time zone in advance you may consider something like

DateTime local;
try {
  //This is for Linux
  local = TimeZoneInfo.ConvertTimeFromUtc(utc,
              TimeZoneInfo.FindSystemTimeZoneById("Europe/Dublin"));
}
catch (TimeZoneNotFoundException) {
  //This is for Windows
  local = TimeZoneInfo.ConvertTimeFromUtc(utc,
              TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time"));
}
Console.WriteLine(local);

Hardly elegant code.

One option is to use the TimeZoneConverter library and combine it with a check of what platform we are executing on

// using System.Runtime.InteropServices;
// using TimeZoneConverter;

public static DateTime GetLocalTime(DateTime utc, string timeZone)
{

    bool isWindows = RuntimeInformation.IsOSPlatform(OSPlatform.Windows);
    if (isWindows) {
        timeZone = TZConvert.IanaToWindows(timeZone);
        // There is also a TZConvert.WindowsToIana method for going the other way
    }

    var local =
        TimeZoneInfo.ConvertTimeFromUtc(utc,
            TimeZoneInfo.FindSystemTimeZoneById(timeZone));

    return local;
}

var utc = DateTime.UtcNow; // 2020-06-23 07:50
var timeZone = "Europe/Dublin";

var local = GetLocalTime(utc, timeZone); // 2020-06-23 08:50

So there is a way around but time zones are still a bit of a mess when dealing with cross-platform code. There is a GitHub issue for aligning time zone identifiers across platforms in .NET Core so check it out and give a thumbs up if it would help you out.

The continued theft of ideas by C#

Simon Reynolds — Fri, 19 Jun 2020 08:00:00 +0000

Back in the good old days, C# was .NET was Windows. Sure there were antique languages like VB.NET and ivory tower academia from F# but real developers used C# and the language was just fine as it was.

Sure, some additions helped, generics were ok even if they did smell suspiciously like Java. But honestly, a lot of the newer "features" of C# are just syntactic sugar that don't really help anything.

I mean, who really needs things like type inference or ternary operators? And that LINQ syntax?! Who can honestly claim that this

var squaredValues = intCollection.Select(x => x * x).ToList();

is clearer and simpler than this?

List<int> squaredValues = new List<int>();
foreach (int i in intCollection)
{
    int squared = i * i;
    squaredValues.Add(squared);
}

But now, now it gets even worse! C# 8.0 has polluted the language with such unnecessary things as nullable reference types. Maybe I like spending hours hunting through code to track down why something is null when it shouldn't be.

As if that wasn't bad enough, now we have new operators too! We have a fancy new "null-coalescing" operator where a simple if statement would suffice.

List<int> mayBeNull = null;

// Who on earth would do this?
List<int> mustNotBeNull = mayBeNull ??= new List<int>();

// When they can do this?
// What does it matter if someone forgets to do the if check
// when it's their tenth time writing code like this today?
List<int> mustNotBeNull = mayBeNull;
if (mustNotBeNull == null)
{
    mustNotBeNull = new List<int>();
}

But worst of all now they've taken ideas from dangerously fringe languages like F#, with such strange concepts as Pattern Matching, even going so far as to be able to use them on tuples!

public enum Hand { Rock, Paper, Scissors }

public static string RockPaperScissors(Hand first, Hand second)
    => (first, second) switch
    {
        (Hand.Rock, Hand.Paper) => "rock is covered by paper. Paper wins.",
        (Hand.Rock, Hand.Scissors) => "rock breaks scissors. Rock wins.",
        (Hand.Paper, Hand.Rock) => "paper covers rock. Paper wins.",
        (Hand.Paper, Hand.Scissors) => "paper is cut by scissors. Scissors wins.",
        (Hand.Scissors, Hand.Rock) => "scissors is broken by rock. Rock wins.",
        (Hand.Scissors, Hand.Paper) => "scissors cuts paper. Scissors wins.",
        (_, _) => "tie"
    };

If something like Rock, Paper, Scissors can be expressed in a single method that will even give a compiler warning if every possible combination isn't covered in the switch statement, then how on earth is a developer supposed to be able to justify a large design or testing budget?!

But it gets even worse, the upcoming C# 9.0 is adding more features inspired by F#! Honestly, who has even heard of a successful company using F# in production?

But no, it had to take inspiration from this "language" (it doesn't even use semicolons). Adding such unnecessary new things as an init accessor that allows you to specify that a property can only be written to at object initialisation.

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

var simon = new Person
{
   FirstName = "Simon",
   LastName = "Reynolds"
};

// Why does it matter that this code is legal?
// Surely we'd all just remember to not make this mistake?
simon.FirstName = "Evan";

public class Person2
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

var simon = new Person2
{
   FirstName = "Simon",
   LastName = "Reynolds"
};

// Is having to learn a new accessor really worth avoiding mistakes like this?
// Who cares that this would be a compiler error instead of a bug report?
simon.FirstName = "Arlo";

What does it matter if a property is mutable and can be changed at any point? If it's not meant to be written to after creation then that's on us as developers to be professional enough to remember not to write to it!

But still that's not enough, C# 9.0 goes further and introduces the idea of a class being an automatically immutable "record" class. Why on earth would anyone want an object that just represents data and is guaranteed not to be accidentally modified? Why would we need an object that is considered equal to another simply because all the properties of it have the same values?

public data class Person // What is this "data" keyword?!
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

// This is the same but what are we really gaining from this brevity?
public data class Person { string FirstName; string LastName; }

// Or even more extreme brevity?
public data class Person(string FirstName; string LastName);

Does it really help to compress 5 lines down to one? How does that make things simpler?

What if we want to change a record? So instead of modifying it we just have to create a new one even though most fields will have the same values? How can that be done without having to copy each field manually?

var simon = new Person("Simon", "Reynolds");
var evan = simon with { FirstName = "Evan" };

var (firstName, lastName) = evan; // ("Evan", "Taite")

Oh.....ok, I guess that's pretty convenient. And granted, we got automatic deconstruction back into separate fields for free as well but still....this can't be that useful in real life scenarios, right?

It's not as if there's an entire application architecture based on recording the entire history of an object at every point in its history instead of just updating a single instance of it, right? Why would we ever need to audit our records and tell you why, how or when a change occurred?

C# needs to drop all these new plans and return to its roots as a plain object-oriented language where anything can be null, state can be changed by anything and where dozens of if/else statements are used instead of single switches that cover all cases. If we carry on down this dangerous path how are we supposed to show our skills? Which will look more impressive, fixing a critical bug at 3AM on a Sunday morning or leaving work on time each day because we've been able to prevent the bug in the first place?

PowerShell in .NET Core and Docker

Simon Reynolds — Tue, 16 Jun 2020 08:00:00 +0000

Since the beginning of ~~time~~.NET Core there has been one continuous annoyance about developing cross-platform solutions, including build scripts for windows and non-windows platforms.

We have at least fallen into a standard pattern, most repositories will contain both a build.cmd and build.sh that will build the project in whichever platform we're currently using.

Sometimes though there's only one or one is neglected in favour of the other. If we're using a build tool like Cake or Fake then we have a simple setup, our build files can just trigger the build logic which is stored in a single file. In fact, both tools will give you default build files that do just that.

So what if we're just doing a relatively plain build task? Something like

dotnet clean

dotnet tool restore

dotnet build ./src/*.csproj

dotnet build ./tests/*.csproj

dotnet test ./tests/*.csproj

dotnet package ./src/*.csproj

Over time changes will be made to this and human error is inevitable, a change will be made to build.cmd but not to build.sh, or vice versa.

Enter PowerShell Core, now available as a dotnet tool! Presuming you have the .NET Core SDK installed, you can simply run

dotnet tool install --global PowerShell

It will now be available with the pwsh command. But this still presumes that other developers will have it installed globally.

Let's add it on a project level.

# add a tool manifest if there isn't one already
dotnet new tool-manifest

dotnet tool install PowerShell

Now PowerShell becomes a tool available in the project. Instead of pwsh, you will have to specify dotnet pwsh but now we can create a build.ps1 file that can contain all our build logic and replace our build.cmd and build.sh files with a one-liner.

dotnet pwsh build.ps1

Now all our build logic is cross-platform without external dependencies!

Where this really comes into its own is that PowerShell has been included as a global tool in .NET Core SDK docker images.

Combined with Visual Studio Code's new Remote Development functionality, this means you can build a truly cross-platform development environment in a docker image. Simply set it up for your project, write one build script in PowerShell and rest secure in the knowledge that you're providing everything needed for another developer to be able to grab your project, open it up and build it immediately without having to worry about setting up dependencies or even what platform they're using!

Developing in a docker container

Simon Reynolds — Sat, 13 Jun 2020 13:26:56 +0000

Ah, a new open source project that looks interesting. Let's pull it down from GitHub, open it up in the IDE of our choice and.... Oh... It turns out the build scripts assume you have some build tool already installed or, even worse, a specific version of it.

This is a great example of where the Remote Development extension pack for Visual Studio Code comes in. Grab it and you can do all your development in a docker container for your projects!

Naturally, you'll need to have Docker installed, either Docker Desktop for Windows or MacOS, or Docker CE/EE for the Linux distribution of your choosing.

And in even better news, with the release of WSL 2, Docker now uses it instead of Hyper-V as the backend, so you can run Docker on Windows 10 Home Edition too! Read more about it here.

Once that's installed all you need to add is a .devcontainer folder in the root of your project and throw in a devcontainer.json file. You can use it to either specify a prebuilt image or specify a DOCKERFILE that you can use to build a custom development environment.

You can use this for any project in any language, I'm going to detail how I use it for a .NET Core project built in F# but the same ideas can be applied to any project.

You can base your Dockerfile on any image, PHP, NodeJS, the .NET Core SDK, whatever tech stack you're building with. Then build on it, add in whatever extra tools you need, maybe you want to add git?

A prebuilt environment containing everything you need, with exactly the versions you want. What more could you need?

But wait...there's more!

Why stop at specifying just your build environment? How about what VS Code settings or extensions are needed?

Let's extend the devcontainer.json with some extra instructions. We can say we want some extensions installed by default. If you use VS Code for F# then you probably already have the amazing Ionide plugin installed.

But you want your project to be easy for newcomers to get up and running. Telling them to go install 5 different extensions just get started isn't the best way to start off a relationship with a potential new user or contributor.

Let's just list the extensions we need instead...

{
    "name": "MyAwesomeApp",
    "dockerFile": "Dockerfile",
    "appPort": [8080],
    "extensions": [
        "ionide.ionide-fsharp",
        "ms-vscode.csharp",
        "editorconfig.editorconfig",        
        "ionide.ionide-paket",
        "ionide.ionide-fake"
    ]
}

What about VS Code settings? All settings in VS Code are specified in json files, so we just add one to the .devcontainer folder and reference it in the Dockerfile.

{
    "FSharp.fsacRuntime":"netcore"
}

This example is named settings.vscode.json so we add it to our Dockerfile

FROM fsharp:netcore

# Copy endpoint specific user settings into container to specify
# .NET Core should be used as the runtime.
COPY settings.vscode.json /root/.vscode-remote/data/Machine/settings.json

# Install git, process tools
RUN apt-get update && apt-get -y install git procps

So now when we open the project in VS Code we get a prompt to reopen it in a container. It will create a Docker container based on the supplied DOCKERFILE, automatically open and forward port 8080 from the container to the host and install all the extensions listed. Now we can happily write our build script that assumes the presence of a build tool and make sure that making changes to it is a smoother experience because VS Code will even have the right extensions for it!

The full reference for what devcontainer.json can do is here, and it can do a lot!

Creating a single file application in .NET Core

Simon Reynolds — Thu, 18 Jul 2019 20:37:09 +0000

.NET Core has long supported the idea of a self-contained application, where the build process results in a single executable application. Until the release of .NET Core 3 preview 6 though, the resulting output would be a single executable and every supporting library or dll that it needed.

Let's examine the changes using a simple Hello World application...

mkdir SingleExe
dotnet new console

This will create a simple console application with a csproj like below

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

If we add a RuntimeIdentifier for our environment we can then publish an application built for that environment that can be ran without requiring the .NET Core runtime to be installed. A breakdown of Runtime Identifiers can be found here.

Once we add the appropriate identifier, e.g. <RuntimeIdentifier>osx-x64</RuntimeIdentifier> we can then publish the application using

dotnet publish -c Release

This will result in a lot of output!

72MB across 191 items is not a small self-contained application!

.NET Core 3 introduces a number of new options for consolidating all this output.

If we update our csproj to the following, then our output will be merged into a single executable and uncalled code will be trimmed from it

<PublishTrimmed>true</PublishTrimmed>
<PublishSingleFile>true</PublishSingleFile>

A single 30MB executable is a lot more manageable

Now, 30MB for an application that in this case simply writes "Hello World" to a console screen may seem excessive but remember that this is including every part of .NET Core that the application needs to run, it has absolutely no external dependencies!

Be careful here though, anything that uses reflection may be incorrectly trimmed.

Test your applications after trimming them! You can tell the trimmer to include specific namespaces, classes or methods using the TrimmerRootAssembly element.

<ItemGroup>
  <TrimmerRootAssembly Include="Namespace.To.Keep" />
</ItemGroup>

This is all still just using IL (Intermediate Language) though, the bytecode that .NET code compiles to and is JIT (Just In Time) compiled to the target machine's native code every time the application is ran.

If we're going to build for a specific platform, or offer builds for multiple platforms then it would make sense to pre-compile as much of the code to native machine code as we can.

Enter the PublishReadyToRun option. We include it in our csproj file so that the whole file now looks like this...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSingleFile>true</PublishSingleFile>
    <PublishReadyToRun>true</PublishReadyToRun>
    <!-- Set the RuntimeIdentifier below to match your own system -->
    <RuntimeIdentifier>osx-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

Now the compiler will pre-compile as much code as it can to (in this case) Mac specific machine code. This will not have to be JITted each time the application runs, leading to a noticeably faster application start.

The tradeoff here is that the resulting executables are now platform specific but if you can provide a pre-built executable for each of the major platforms then it could be well worth considering.