PowerShell require minimum version

Friday, 18 October 2019

I have some PowerShell scripts that had a dependency on using at least PowerShell 4.0. I’d added #Require -Version 4.0 to the top of the script, but was surprised the other day when this script ran on a machine with only PowerShell 2.0 and it didn’t complain. Well it did complain about other things (related to trying to run on the older version), but it didn’t throw up an error about the wrong version immediately like I’d expected.

Double-checking the documentation for About_Requires, I realised I’d made a minor (but significant) typo.

#Requires -Version 4.0

Yeah - a missing ‘s’. Without that, it’s just a commented line rather than a directive, so it was having no effect.

As it happens, this script also needs to be run as an Administrator, and whilst browsing same the documentation discovered there’s also a Requires prerequisite for that too!

#Requires -RunAsAdministrator

Trying to run the script non-elevated results in the following error:

.\Script.ps1 : The script 'Script.ps1' cannot be run because it contains a "#requires" statement for running as Administrator. The current PowerShell session is not running as Administrator. Start PowerShell by using the Run as Administrator option, and then try running the script again.

My .NET Conf 2019 talk - Publish or Perish

Monday, 7 October 2019

The recording from my presentation ‘Publish or perish - tricks to successfully ship your NET Core 3 app’ that was part of .NET Net Conf is now up on YouTube.

The source for the demos are in this GitHub repository

Speaking at .NET Conf 2019

Saturday, 14 September 2019

.NET Conf 2019 I’m really looking to .NET Net Conf, particularly as I’ll be one of the speakers!

.NET Conf kicks off on 23rd September 16:00 UTC / 24th September 01:30 +930. It’s a virtual conference where all the speakers appear online.

I’m presenting a talk on new publishing options for .NET Core 3 apps. If you’d like to see me live, tune in on 25th September 04:00 UTC / 13:30 +930

We’re also hosting an Adelaide local .NET Conf event next month as part of the Adelaide .NET User Group, with David Wengier speaking about Pragmatic Performance. Sign up here.

DDD Adelaide 2019 is coming!

Sunday, 1 September 2019

It was first announced a few weeks ago, but it deserves a mention here too - DDD Adelaide 2019 is happening on Saturday 23rd November!

Andrew Best (Principal Consultant at Readify) has taken the organisational initiative and I’m exciting to be working with him to bring a day-long conference for all software developers to Adelaide.

Long-time readers may remember we have actually had some events in Adelaide before. Indeed I blogged about the last DDD way back in 2011. In the intervening time, DDDs have been happening all around Australia. Melbourne, Sydney, Brisbane and Perth are all now running annual DDD conferences. They’ve grown to become significant events (many selling out within hours of tickets being made available!), and some now regularly have 700-800 attendees (big enough that they have to book a proper convention centre for their venue).

So the DDD we’re putting on this year is going to be a little different to anything that has ever happened in Adelaide before. It’s going to be bigger and better (with two tracks), and is open to any and all software developers (plus related fields) and any programming language, technology, ecosystem, cloud, little and big-endian!

While we’re not aiming to be quite as large our interstate cousins, I think if this year’s event is well supported by the local developer community, then the only way is up for the future.

DDD is run as a non-profit event. So while we are charge for registration, this covers the cost of providing catering for the day. There’s other costs with running DDD, so it’s great to have some big-name sponsors also supporting us. In fact there’s still room for more sponsors to get on board.

So what happens between now and November 23rd?

Registrations are open now. Sign up to attend now!

The Call for Presentations closes at the end of Wednesday September 4th. If you’ve got something you’d be prepared to present to a group of interested people, submit it now!

The following week (12th September to be precise), the full list of proposed sessions will be published for registered attendees to vote on. Yes, the people who are going to attend get to vote on which sessions they want to see. Yet another incentive to register.

After voting closes (27th September) and we’ve confirmed presenter availability then the final agenda will be published (3rd October).

So sign up and I’ll see you on the 23rd. It’s going to be awesome!

Modifying and extending Topshelf

Saturday, 17 August 2019

Topshelf is a useful library if you have a .NET application that you would like to easily turn into a Windows Service.

A common approach is to create a console application, wire in Topshelf and then you can run it as either a console app or install and start it as a Windows service.

One thing I encountered this week was that by default Topshelf changes the current directory to the location of your .exe when your application runs. This makes sense because otherwise the default current directory for a Windows service is actually c:\windows\system32! If you’re trying to load additional files from the same directory as the .exe then that’s not where you’d want to be looking so Topshelf’s alteration makes sense.

But what about for debugging?

In Visual Studio, when you press F5 to debug a web project (which is the kind I was working with), the current directory defaults to the project’s directory. Again you may have logic that makes assumptions about other resources that need to be loaded relative to the project directory - if you’re now using Topshelf that’s going to break as the current directory will be changed. How to fix this?

Stepping through the Topshelf source code, I realised that I wanted a version of ConsoleRunHost that didn’t have the calls to Directory.SetCurrentDirectory(). That class is instantiated by the RunBuilder class, which in turn is returned by the DefaultHostBuilderFactory method in HostConfiguratorImpl.

So that’s the default factory, but the same class also provides a UseHostBuilder method that allows you to provide your own factory instead. That’s just what I needed.

By adding my own factory method that returned an instance of my own custom RunBuilder, which then returned a custom ConsoleRunHost implementation that was identical to Topshelf’s ConsoleRunHost with the exception that it didn’t change the default directory.

private static HostBuilder HostBuilderFactory(HostEnvironment environment, HostSettings settings)
    return new MyRunBuilder(environment, settings);

And tell Topshelf to use this method by calling UseHostBuilder:

var rc = HostFactory.Run(x =>

If you wanted to, you could even check if you were running under the debugger to decide whether to use the default or custom behaviour.

It’s nice when libraries have thought about extensibility and provide hooks for consumers to swap in custom logic.