[JeremyCamplin]

Background

Noted while using this template that in the output it was duplicating rows.
On closer inspection, found these issues:

• Duplicate output. The ASP.NET Core check printed the same version several times. It regex-scanned HKLM\SOFTWARE\Wow6432Node\Microsoft\Updates\.NET Core and ...\Updates\.NET, where each version has one key per architecture plus the hosting bundle key.
• TargetVersion ignored for ASP.NET Core. That half of the script only tested whether the list was non-empty, so it passed as long as any ASP.NET Core entry existed.
• String comparison. Versions were compared with $_ -ge $targetVersion on strings, so "10.0.14" -ge "6.0" is $false and .NET 10 runtimes are never matched, while "6.0.9" -ge "6.0.10" is $true.

Results

• Both runtimes are discovered from <Program Files>\dotnet\shared\Microsoft.NETCore.App and ...\shared\Microsoft.AspNetCore.App, one folder per version, which is the same source dotnet --list-runtimes uses. No duplicates, no registry dependency, and no 32-bit registrations counted as usable runtimes.
• Versions are compared numerically with SemVer precedence: 10.0 > 6.0, 6.0.9 < 6.0.10, and a pre-release such as 10.0.0-rc.1.25451.107 is lower than 10.0.0. A bare major such as 8 is treated as 8.0.
• The ASP.NET Core check applies the same TargetVersion and Exact rules as the .NET runtime check.
• Failure messages now list the installed versions, and an unparseable TargetVersion fails fast with a clear message.
• The 64-bit Program Files folder is used even when the script runs in a 32-bit PowerShell host.
• Help text updated for all three parameters, and the checkbox is relabelled "Check ASP.NET Core Runtime" to describe what it actually checks. Parameter names are unchanged so existing steps keep their configured values.

Before

Target 6.0, Exact off, ASP.NET Core check on.
ASP.NET Core versions are repeated, 8.0.2 is a 32-bit registry entry, and the installed x64 8.0.8 is missing:

Found .NET Core Runtime 6.0.2 installed in the machine.
Found .NET Core Runtime 8.0.2 installed in the machine.
Found .NET Core Runtime 8.0.8 installed in the machine.
Found ASP.NET Core Runtime 3.1.13 installed in the machine.
Found ASP.NET Core Runtime 3.1.13 installed in the machine.
Found ASP.NET Core Runtime 3.1.13 installed in the machine.
Found ASP.NET Core Runtime 5.0.17 installed in the machine.
Found ASP.NET Core Runtime 5.0.17 installed in the machine.
Found ASP.NET Core Runtime 6.0.2 installed in the machine.
Found ASP.NET Core Runtime 6.0.2 installed in the machine.
Found ASP.NET Core Runtime 8.0.2 installed in the machine.

What dotnet --list-runtimes reports on that same server:

Microsoft.AspNetCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

On a second machine with .NET 10 installed (runtimes 6.0.36, 8.0.19, 8.0.32, 8.0.33, 10.0.11, 10.0.12, 10.0.14), the same parameters miss every .NET 10 runtime because of the string comparison:

Found .NET Core Runtime 6.0.36 installed in the machine.
Found .NET Core Runtime 8.0.19 installed in the machine.
Found .NET Core Runtime 8.0.32 installed in the machine.
Found .NET Core Runtime 8.0.33 installed in the machine.
Found ASP.NET Core Runtime 5.0.17 installed in the machine.

After

Same parameters on the first server, from a runbook run of the updated template. The output now matches dotnet --list-runtimes:

Found .NET Core Runtime 6.0.2 installed in the machine.
Found .NET Core Runtime 8.0.2 installed in the machine.
Found .NET Core Runtime 8.0.8 installed in the machine.
Found ASP.NET Core Runtime 6.0.2 installed in the machine.
Found ASP.NET Core Runtime 8.0.8 installed in the machine.

Target 10.0 on the same server:

Can't find .NET Core Runtime 10.0 or greater installed in the machine. Installed versions: 3.1.13, 5.0.17, 6.0.2, 8.0.2, 8.0.8.

Target 6.0 on the second machine, with .NET 10 now matched and ASP.NET Core read from the same source as the runtime:

Found .NET Core Runtime 6.0.36 installed in the machine.
Found .NET Core Runtime 8.0.19 installed in the machine.
Found .NET Core Runtime 8.0.32 installed in the machine.
Found .NET Core Runtime 8.0.33 installed in the machine.
Found .NET Core Runtime 10.0.11 installed in the machine.
Found .NET Core Runtime 10.0.12 installed in the machine.
Found .NET Core Runtime 10.0.14 installed in the machine.
Found ASP.NET Core Runtime 6.0.36 installed in the machine.
Found ASP.NET Core Runtime 8.0.33 installed in the machine.
Found ASP.NET Core Runtime 10.0.14 installed in the machine.

Also tested with Windows PowerShell 5.1 against a synthetic dotnet\shared tree covering .NET 10 ordering, pre-release ordering, exact matching, ASP.NET Core filtering, invalid and empty targets, and a missing dotnet folder.

Pre-requisites

• Id should be a GUID that is not 00000000-0000-0000-0000-000000000000
  • NOTE If you are modifying an existing step template, please make sure that you do not modify the Id property (updating the Id will break the Library sync functionality in Octopus).
• Version should be incremented, otherwise the integration with Octopus won't update the step template correctly
• $Meta must have ExportedAt and OctopusVersion updated
• Parameter names should not start with $
• Step template parameter names (the ones declared in the JSON, not the script body) should be prefixed with a namespace so that they are less likely to clash with other user-defined variables in Octopus (see this issue). For example, use an abbreviated name of the step template or the category of the step template).
• LastModifiedBy field must be present, and (optionally) updated with the correct author
• The best practices documented here have been applied
• If a new Category has been created:
  • An image with the name {categoryname}.png must be present under the step-templates/logos folder
  • The switch in the humanize function in gulpfile.babel.js must have a case statement corresponding to it

[github-actions]

Review this PR in Hyponome for a side-by-side diff of the step-template JSON and any embedded scripts.