Wow, that escalated fast. In the space of just a few weeks:

• The MVP Summit trip to Seattle and Redmond was cancelled (and replaced with a virtual conference).
• My daughter’s school long anticipated school trip to Spain has been cancelled/deferred.
• Massive government interventions.
• People are dying.
• Many people (particularly those in service industries) are (or soon will be) doing it really tough.
• Our family is increasing our social distance as much as possible.
• I’m planning to run the next few months of ADNUG as online virtual meetings.
• I’m now working from home for the forseeable future. I appreciate that my job allows me to do that - not everyone has that option.

To avoid being cooped up in the house the entire day, the last couple of mornings before starting work I’ve gone for a short walk around the neighbourhood with my other daughter. It emulates my walk to the bus stop. Hopefully we can make it a regular thing.

Apparently my legs are a bit longer than hers, so a short break on a seat in the park along the way is required :-)

This is going to be a very disruptive time. Things aren’t too bad (yet) where I live, but the stories from overseas are quite scary. Take care of yourselves and your loved ones.

January and February have come and gone, and March is now well underway. Autumn seems to have definitely hit Adelaide, though I wonder if there might still be some warmer weather around before Winter arrives? Time will tell.

Out of the ordinary

• This year was the first in a long time that we didn’t take part in the Tour Down Under community ride. The route wasn’t particularly inspiring this year, so we gave it a miss. Hopefully 2021 will be better and the Gardiner boys will be back in lycra, raring to go!
• I was all booked to fly over to Seattle/Redmond to attend Microsoft’s annual MVP Summit, but it was announced this week that it has been cancelled, and an online/virtual event will be run in its place. Thank Coronavirus for making this one of many large events that have been impacted. So, I’m staying in Adelaide instead of cramming myself into an international economy seat for 24 hours (plus the return flight home). As I said on Twitter, it is disappointing but I think Microsoft made the right call considering the circumstances.

Also interesting to read about Microsoft asking their Redmond-based employees to work from home (if possible) for the rest of March.

ADNUG

The Adelaide .NET User Group is back for 2020. There’s been huge interest in next week’s meeting, which is great to see. I’m hoping to fill out the speaker schedule for the next few months. Do get in touch if you’d like to present to the group (and that can be in-person, or remote via Skype/Teams).

If I have one wish for the group, it’s that I could find someone(s) to share the organising with. It would be good to have some load balancing (or at least a fail-over cluster!) Related to that, we’ve actually launched the ADNUG 2020 Member Survey. Please share your thoughts (and be in the running for a $100 book voucher).

I must say it’s been really great to have Simon and Kristine from Encode Management on-board as both sponsors and supporters - and I know they’re also working with other meetups in Adelaide too. It would be easy (and I think it has happened in the past) that sponsors just give some money, or might just pop their head in, but the folks from Encode are regular attendees and are often one of the last to leave after helping pack up. That sincerity and encouragement count for a lot in my book. And speaking of books, it’s Encode that are putting up the aforementioned book voucher. Awesome!

DDD Adelaide 2020

I caught up with Andrew this week to kick of planning for DDD Adelaide 2020, with our traditional ‘DDDumplings’ lunch meeting. We should really get Dumpling King on board as a major sponsor :-)

Christmas has come and gone, and now it’s 2020. If there’s one thing that’s been a constant over this Summer period, it’s that it feels like we’re under seige from bushfires.

Here’s a view not that far from where I live. That’s a smoke haze (not really thick, but noticeable ), from fires on Kangaroo Island around 200km south. There’s been other fires around South Australia in the Adelaide Hills and over on York Peninsula. And then interstate there’s fires all over the place - basically all around Australia. A good drop of rain would not go astray.

I’ve been enjoying some time off - catching up with family, the odd bike ride or two, a few jobs around the house and just trying to switch off for a bit.

More to come…

A Runtime Identifier (RID) is used to identify target platforms where a .NET Core application runs. They come into play when packages contain platform-specific assets (eg. native code for Linux, or Windows 64bit).

You can specify a single RID using the <RuntimeIdentifier> element in the project file, or to specify multiple RIDs use <RuntimeIdentifiers>.

Many dotnet command also can specify --runtime (or -r).

According to the documentation, if you only need to specify a single runtime then using <RuntimeIdentifier> will also result in faster builds.

I’ve noticed some other subtle difference between the singular and plural forms of this element.

Let’s create a simple .NET Core console app:

md rid
cd rid
dotnet new console

By default, the csproj (named rid.csproj in this case) looks like this:

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

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

</Project>

If you look inside the obj directory, you’ll find a file named rid.csproj.nuget.dgspec.json. Its contents look like this:

{
  "format": 1,
  "restore": {
    "C:\\tmp\\rid\\rid.csproj": {}
  },
  "projects": {
    "C:\\tmp\\rid\\rid.csproj": {
      "version": "1.0.0",
      "restore": {
        "projectUniqueName": "C:\\tmp\\rid\\rid.csproj",
        "projectName": "rid",
        "projectPath": "C:\\tmp\\rid\\rid.csproj",
        "packagesPath": "C:\\Users\\david\\.nuget\\packages\\",
        "outputPath": "C:\\tmp\\rid\\obj\\",
        "projectStyle": "PackageReference",
        "fallbackFolders": [
          "C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder"
        ],
        "configFilePaths": [
          "C:\\Users\\david\\AppData\\Roaming\\NuGet\\NuGet.Config",
          "C:\\Program Files (x86)\\NuGet\\Config\\Microsoft.VisualStudio.Offline.config"
        ],
        "originalTargetFrameworks": [
          "netcoreapp3.1"
        ],
        "sources": {
          "C:\\Program Files (x86)\\Microsoft SDKs\\NuGetPackages\\": {},
          "https://api.nuget.org/v3/index.json": {}
        },
        "frameworks": {
          "netcoreapp3.1": {
            "projectReferences": {}
          }
        },
        "warningProperties": {
          "warnAsError": [
            "NU1605"
          ]
        }
      },
      "frameworks": {
        "netcoreapp3.1": {
          "imports": [
            "net461",
            "net462",
            "net47",
            "net471",
            "net472",
            "net48"
          ],
          "assetTargetFallback": true,
          "warn": true,
          "frameworkReferences": {
            "Microsoft.NETCore.App": {
              "privateAssets": "all"
            }
          },
          "runtimeIdentifierGraphPath": "C:\\Program Files\\dotnet\\sdk\\3.1.100\\RuntimeIdentifierGraph.json"
        }
      }
    }
  }
}

If you supply a runtime identifier when running restore, like dotnet restore -r win10-x64, then two extra sections are added to this file. Firstly, under the "netcoreapp3.1" node:

          "downloadDependencies": [
            {
              "name": "Microsoft.AspNetCore.App.Runtime.win-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.NETCore.App.Runtime.win-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.WindowsDesktop.App.Runtime.win-x64",
              "version": "[3.1.0, 3.1.0]"
            }
          ]

and secondly under the second "C:\\tmp\\rid\\rid.csproj" node, a runtimes section is added:

      "runtimes": {
        "win10-x64": {
          "#import": []
        }
      }

If you instead passed in -r linux-x64 then predictably, those entries refer to linux-x64 instead of win-x64.

Adding <RuntimeIdentifier>win10-x64</RuntimeIdentifier> to the csproj and running dotnet restore has exactly the same effect as if you specified the RID on the command line.

And now running dotnet build with the RID specified results in the compiled application being created in bin\Debug\netcoreapp3.1\win10-x64. Plus, since .NET Core 3 it also defaults to creating a self-contained application (so you get an .exe as well as all the dependent assemblies to allow you to run the application on a machine that didn’t already have the runtime installed)

It’s a slightly different story if you use <RuntimeIdentifiers> though..

You can’t specify multiple RIDs on the command line (well actually in .NET Core 2.2 you could for restore, but not in 3). So let’s change our csproj to have <RuntimeIdentifiers>win10-x64;linux-x64</RuntimeIdentifiers>. and run

dotnet restore

the dgspec.json now contains entries for both platforms. eg.

          "downloadDependencies": [
            {
              "name": "Microsoft.AspNetCore.App.Runtime.linux-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.AspNetCore.App.Runtime.win-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.NETCore.App.Host.linux-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.NETCore.App.Runtime.linux-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.NETCore.App.Runtime.win-x64",
              "version": "[3.1.0, 3.1.0]"
            },
            {
              "name": "Microsoft.WindowsDesktop.App.Runtime.win-x64",
              "version": "[3.1.0, 3.1.0]"
            }
          ],

and

      "runtimes": {
        "linux-x64": {
          "#import": []
        },
        "win10-x64": {
          "#import": []
        }
      }

but now if you run dotnet build, something interesting… there’s no bin\Debug\netcoreapp3.1\win10-x64 or bin\Debug\netcoreapp3.1\linux-x64 directories like you might be expecting. Instead there’s just the regular compiled assembly in bin\Debug\netcoreapp3.1! Almost as if you’d never set a RID at all.

What you can do now though, is build for both platforms consecutively. eg.

dotnet build -r win10-x64
dotnet build -r linux-x64

and you get both self-contained builds for win10-x64 and linux-x64 platforms! Plus, as you’ve already done a restore, you can make the build faster by passing in --no-restore so it doesn’t bother trying to restore again.

So if you’re targetting a single platform, use -r on the command-line or <RuntimeIdentifier>. If you’re targetting multiple platforms, use <RuntimeIdentifiers> and then use separate restore and build steps

Last Saturday, we ran DDD Adelaide 2019. When we were setting up the venue on Friday afternoon, I realised that there was a huge flat-screen TV in the open area (behind where the registration/info desk would be located) and we hadn’t made any plans to use it.

We could just pop a copy of the DDD logo on a USB stick and probably the TV could just show that in ‘slide-show’ mode. But then I thought maybe we could go one better. Wouldn’t it be nice if you could display a simple ‘What’s on now, and what’s coming up next’ dashboard?

Ok, it’s Friday night, and I really should have been heading to bed, but I’d been inspired - now to find something that would fit the bill. A quick search of GitHub didn’t reveal anything obvious, so can I write a simple application myself to do the job?

First question - WPF, WinForms? HTML+JavaScript? They’d all do the job, but I wanted something simple that I could get done quickly! I decided I’d give PowerShell a go - and I kind of liked the idea of making it “old-school” ASCII text too.

I copied over the conference agenda data and decided on simple ordered dictionary would suffice for the data structure, using the time as the key. Then just two queries - one to find the entry who’s time is now, and the second to find the entry for what’s coming up next.

To help with development, I added a -test mode, that sped up time and made the clock run from 7am. Later on Saturday I realised I had an ‘off by one’ bug in the query logic - the test mode was useful to validate the fix.

One extra touch - I added a ‘current time’ and used [Console]::SetCursorPosition() to locate that in the bottom right-hand corner. While I was at it, just to be fancy, I added some colour to the ‘DDD’ bit in the title.

To run the dashboard, I used Windows Terminal. That allowed me to run full screen and choose a nice font size.

The dashboard worked well and I heard a few compliments that people liked it. Not bad for something whipped up in an hour!

If I revisit the script in the future, I might see if I can incorporate a simple Tweet wall - either on the right-hand side, or maybe alternating every 30 seconds. There was a lot of Twitter traffic on the day and it would have been nice to showcase that.

The source is all on GitHub. Pull requests welcome!