David Gardiner

Mar 6, 2020
March update
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 :-)
Jan 9, 2020
Welcome to 2020
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…

Dec 5, 2019

.NET RuntimeIdentifier vs RuntimeIdentifiers

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

March update

Out of the ordinary

ADNUG

DDD Adelaide 2020

Welcome to 2020

.NET RuntimeIdentifier vs RuntimeIdentifiers