David Gardiner - .NET

.NET Azure Function error - A connection string was not found

2026-06-11T23:00:00.000+09:30

I'm trying out running .NET Azure Functions on my new laptop, and thought I'd start from scratch by creating a brand new .NET Azure Function project.

I installed the Azure Function Core Tools using Homebrew. (Note that official instructions missed the 'trust' command):

brew tap azure/functions
brew trust azure/functions
brew install azure-functions-core-tools@4

I then created a new Function project using the CLI, following these instructions.

func init --worker-runtime dotnet-isolated --language csharp

And then attempt to run it:

dotnet run

And was greeted by this error:

Failed to start language worker process for runtime: dotnet-isolated. workerId:80487f5d-6d73-4858-a55a-2e56d0853367
Language Worker Process exited. Pid=4680.
Microsoft.Azure.WebJobs.Script.Grpc: dotnet exited with code 134 (0x86). Unhandled exception. System.InvalidOperationException: A connection string was not found. Please set your connection string.
Removing errored webhost language worker channel for runtime: dotnet-isolated workerId:80487f5d-6d73-4858-a55a-2e56d0853367
Microsoft.Azure.WebJobs.Script.Grpc: dotnet exited with code 134 (0x86). Unhandled exception. System.InvalidOperationException: A connection string was not found. Please set your connection string.
A host error has occurred during startup operation '67dfffee-7a1e-4970-9014-209232677f0f'.
Microsoft.Azure.WebJobs.Script.Grpc: dotnet exited with code 134 (0x86). Unhandled exception. System.InvalidOperationException: A connection string was not found. Please set your connection string.
Failed to stop host instance 'a4c866ff-2d8e-4423-b022-308f56a22348'.
Microsoft.Azure.WebJobs.Host: The host has not yet started.
meter 'provider')
Host startup operation has been canceled

That's a weird error. My Function app is pretty much empty - there's the Program.cs file but I haven't even added any actual Functions yet!

A bit of searching and throwing the error at Copilot turned up the suggestion that it's the UseAzureMonitorExporter() method call that is added by default in Program.cs that is the culprit:

builder.Services.AddOpenTelemetry()
    .UseFunctionsWorkerDefaults()
    .UseAzureMonitorExporter();

It is throwing an error because APPLICATIONINSIGHTS_CONNECTION_STRING environment variable has not been set. It's a pity the error message was not more descriptive.

The solution is to either change the code so that UseAzureMonitorExporter() is only called if that environment variable has been set, or alternatively make sure that it is set.

For local development you can add it to your local.settings.json file. If you don't have a real App Insights resource to point to, you can set it to InstrumentationKey=00000000-0000-0000-0000-000000000000 which is recognised as a "null" connection string. With that value it no longer fails, but all traces and telemetry are just ignored.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "APPLICATIONINSIGHTS_CONNECTION_STRING": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
}

If you deployed this Function App to Azure, you would ideally have a real Application Insights resource, and had set the APPLICATIONINSIGHTS_CONNECTION_STRING to point to it.

See Connection strings in Application Insights for more info about what options there are for connection strings.

Not an ideal experience. Hopefully they'll update the generated code so that it includes that so things work right out of the box.

Fatal error 0x8013132d debugging .NET 10 applications in Visual Studio

2026-04-10T12:00:00.000+09:30

Trying to debug an Aspire .NET 10 application in Visual Studio today and hitting this error:

A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support web site. HRESULT=0x8013132d. ErrorCode=0x0.

A bit of searching online turned up this bug report on the Microsoft Developer Community site.

That was eventually forwarded to the .NET runtime repo on GitHub where it was identified as relating to a breaking change introduced in .NET 9

This change improves the security of .NET applications, but in this case is stopping me from being able to debug.

You can opt out of this new behaviour by adding the following property to your csproj:

<CETCompat>false</CETCompat>

Given in my case the problem only happens when I'm debugging, then it would be preferable to leave this new feature on by default, so I've added a condition to the property like this:

<CETCompat Condition="'$(Configuration)' == 'Debug'">false</CETCompat>

In my Aspire AppHost csproj file, the PropertyGroup element looks like this:

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <UserSecretsId>00000000-0000-0000-0000-000000000000</UserSecretsId>
    <CETCompat Condition="'$(Configuration)' == 'Debug'">false</CETCompat>
  </PropertyGroup>

Exceptional unit tests

2026-04-01T09:30:00.000+10:30

I was working on a .NET application that had a nice suite of unit tests, and pleasingly the tests were all passing.

While making a change to the code, one of the tests failed (which is the whole point of having tests!). To better understand the reason for the failure I re-ran the test in the Visual Studio debugger.

I noticed something strange - the system under test was throwing a NullReferenceException, which was then being caught (and effectively swallowed) by an outer try/catch block.

The surprising thing was that this test should not have been doing that - a pretty straightforward test of some business logic. It was just a coincidence that in this case the exception wasn't changing the observable behaviour of the code, which is why the test had previously been passing.

In this case, the underlying cause of the NullReferenceException turned out to be a missing mocked method on a dependency.

It did make me wonder though, are there other similar issues hidden elsewhere in the unit tests?

To find out, I opened up Visual Studio's Exception Settings window (Debug | Windows | Exception Settings), searched for 'NullReferenceException' and ensured that it was set to 'Break when thrown'

I then ran the entire test suite under the debugger (Test | Debug All Tests) and took note of each time the debugger stopped with a thrown exception. Some of these were other exception types that were expected (and I could turn off the 'Break when thrown' on those if they were too noisy).

I ended up finding a few other tests that had similar issues. There were also some paths in the application code where null handling could be made more robust.

The tests still pass, but they should now be a bit more reliable in the future for the next developer who is relying on them when making application code changes (which could be me!)

Best of C# 14 - extension members

2026-03-17T08:00:00.000+10:30

Extension methods were introduced way back in 2007 with C# 3. But they only allowed you to add methods to an instance type. Extension Members, a new feature of C# 14, finally 'extend' this concept to properties and static members too.

The classic extension method definition looks like this:

public static class MyExtensions
{
    public static int WordCount(this string str) =>
        str.Split([' ', '.', '?'], StringSplitOptions.RemoveEmptyEntries).Length;
}

The class needed to be static, and the static method's first parameter needs the this modifier.

That style of extension method hasn't gone away, and you're free to keep doing it that way if you like.

But now we can create extension properties or extension methods on types. To do that there's a new extension keyword that is used to create extension blocks. You can use these for extension properties, and extension methods, and also for both of these for types in addition to instances.

public static class Enumerable
{
    // Extension block
    extension(string str) // extension members for string instances
    {
        // Extension method:
        public int WordCount() =>
            str.Split([' ', '.', '?'], StringSplitOptions.RemoveEmptyEntries).Length;

        // Extension property:
        public bool Is80CharsLong =>
            str.Length == 80;
    }    

    extension(string)
    {
        // extension method
        public static string ToTitleCase(string str) =>
            System.Globalization.CultureInfo.CurrentCulture.TextInfo.ToTitleCase(str);

        // extension property
        public static string TwoSpaces => "  ";
    }
}

You use these extension members like this:

var sentence = "This is a sentence of words.";

int wordCount = sentence.WordCount();

var is80CharsLong = sentence.Is80CharsLong;

var title = string.ToTitleCase("hello world");

var indent = string.TwoSpaces;

It's another useful language tool. Used appropriately it could make your codebase easier to understand and allow you to separate concerns.

Possible reasons for not using an `extension` block

I've read that some library authors encountered issues when they migrated their old extension methods to extension blocks and the libraries were targeting older frameworks besides .NET 10. If you need to target older frameworks then test this thoroughly first.
If all you're doing is creating extension methods (no properties or type methods), then it's fine to stick with the old syntax.

Best of C# 14 - field keyword

2026-03-10T22:30:00.000+10:30

C# 14 shipped back in November last year along with .NET 10. I've already given a presentation a number of times on my highlights of .NET 10, which included three features of C# 14 that I think are particularly useful.

The first I'm going to focus on is the new field keyword.

The problem this solves is where you'd really like to avoid having to declare a backing field, but prior to C# 14 as soon as you wanted to include any kind of logic in a getter or setter, then you couldn't use auto properties, but instead you needed to provide a backing field and implement the getter and setter. eg.

private string _msg;
public string Message
{
    get => _msg;
    set => _msg = value ?? throw new ArgumentNullException(nameof(value));
}

Because we're adding validation to the setter, that forced us to introduce the _msg field. And if you can be disciplined that's fine, but the trap is there's nothing to stop other code in the same class from also referencing that, even if it shouldn't. The compiler won't stop you.

To help with scenarios like this, and to reduce the amount of code you need to write, C# 14 introduces the field keyword. It's a way to reference the compiler-generated backing field, but only within the property's getter and setter. Our code now becomes:

public string Message
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(value));
}

Our line count is one less, plus we're now not exposing the backing field outside of the property.

Under the hood

When the C# compiler turns the original code into IL (Intermediate Language), it creates something like this:

.field private string _msg

That's how IL represents a regular field.

And if you search the IL generated by code that uses the field keyword, you'll still see a .field entry, but the name is a bit different:

.field private string '<Message2>k__BackingField'
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
      = (01 00 00 00 )
    .custom instance void [System.Runtime]System.Diagnostics.DebuggerBrowsableAttribute::.ctor(valuetype [System.Runtime]System.Diagnostics.DebuggerBrowsableState)
      = (01 00 00 00 00 00 00 00 )

<Message2>k__BackingField is not a valid C# identifier, so there's no chance of being able to reference this field by name elsewhere in your C# code. That DebuggerBrowsableAttribute also means that your debugger will choose to not show the field.

But because the compiler knows the name it has assigned to the field, it generates the correct IL for you when you use the field keyword.

Here's the IL generated for the property setter:

IL_0000: ldarg.0      // this
IL_0001: ldarg.1      // 'value'
IL_0002: dup

IL_0003: brtrue.s     IL_0011
IL_0005: pop
IL_0006: ldstr        "value"
IL_000b: newobj       instance void [System.Runtime]System.ArgumentNullException::.ctor(string)
IL_0010: throw
IL_0011: stfld        string Stuff::'<Message>k__BackingField'
IL_0016: ret

The stfld instruction is saving the current value from the stack into the the compiler-generated backing field.

Reasons for not using `field`

If you have legitimate reasons for accessing the backing field elsewhere in the class (such as multiple properties that reference or share the same backing field).
Thread safety using volatile, Interlocked or lock patterns.
Lazy initialisation/caching patterns
Serialization or reflection that makes assumptions about field names

Aspire with Python, React, Rust and Node apps

2025-11-17T08:00:00.000+10:30

Aspire (formerly .NET Aspire) is a great way to create observable, production-ready distributed apps by defining a code-based model of services, resources, and connections. It simplifies local development and debugging, as well as deployment.

By their very nature, distributed applications will have at least a few (if not a lot) of components. This presents a challenge both for the local developer experience and for deployment. Aspire seeks to simplify this by allowing you to model the services, resources, and connections in code. With one command you can then not only launch everything locally, but ensure that each service knows how to connect to the other services it needs to function.

You can use it for both development and deployment, or if you already have an existing deployment process you're happy with (eg. Infrastructure as Code/deployment pipelines) you can just use Aspire to simply your local development experience.

Check out my previous post Introducing Aspire for an overview of what Aspire is and how it works.

As part of this year's .NET Conf virtual conference, I presented a talk "Taking .NET out of .NET Aspire - working with non-.NET applications", in which I show how despite Aspire being written in .NET, it can integrate with a whole range of other software languages ecosystems. Here's the recording of that presentation:

One issue with the talk was that it had to be pre-recorded a couple of weeks beforehand, so it was done using the Aspire 9.5 bits. Now that Aspire 13.0 is out, some of the packages that I used from the Community Toolkit in the demo are no longer necessary as Aspire has improved the integration with Python and Node.js applications.

The source code for the demo can be found at https://github.com/flcdrg/aspire-non-dotnet. A quick glance and you might think "there's no .NET or Aspire in this repo" and if you just look at the main branch then you'd be right. There are separate branches where I incrementally integrate each component into Aspire.

The scenario I demo is a 'Pet supplies' e-commerce website, with a React front-end, Python backend API running with MongoDB. The Python backend also talks to a Rust-based payment gateway service, and as a bonus step right at the end I add a Node.js server app to provide random pet jokes!

The technology mix is not unheard of, particularly at some larger organisations where you may have different teams working on different features or services and sometimes they are allowed enough autonomy to choose their own technology stack. Whether this is a case of "using the right tool for the job" or "must use the current shiny new thing" isn't so important. The reality is that for good or other reasons you often find yourself in this situation.

MongoDB

MongoDB is supported out of the box in Aspire. The original process was to launch this via docker compose. Aspire actually supports compose files too (via the Aspire.Hosting.Docker package), but in this case I'm taking advantage of the Aspire.Hosting.MongoDB to configure the MongoDB service, database, and for bonus points, include the Mongo Express management UI. This will still run in a Docker container, but Aspire handles all the configuration for me.

var mongo = builder.AddMongoDB("mongo")
    .WithDataVolume()
    .WithMongoExpress();

var mongodb = mongo.AddDatabase("petstore");

WithDataVolume() means that a Docker volume is created to persist the database data between runs.

The original implementation also has a PowerShell script to populate the database with sample data. I wired up that script so that it gets run automatically when the MongoDB service starts up in Aspire.

var loadData = builder.AddExecutable("load-data", "pwsh", "../mongodb", "-noprofile", "./populate.ps1")
    .WaitFor(mongo)
    .WithArgs("-connectionString")
    .WithArgs(new ConnectionStringReference(mongo.Resource, false));
//.WithExplicitStart();

The script conveniently already had a parameter defined to pass in a connection string, so I take advantage of that.

If you'd prefer to just run the script manually (rather than every time you start Aspire) you could uncomment the .WithExplicitStart() method.

Rust

I've never used the Rust programming language before, but it is becoming increasingly popular, especially where you might previously have used C or C++. Rust uses Cargo as its package manager and build tool. Support for building and running Rust applications is provided by the Community Toolkit's CommunityToolkit.Aspire.Hosting.Rust package.

Configuring the Rust application is quite straightforward with the AddRustApp method. The application has a default port it listens on but allows that to be overridden via the PAYMENT_API_PORT environment variable. Aspire will set that to the appropriate port number by the call to WithHttpEndpoint.

var rust = builder.AddRustApp("rustpaymentapi", "../RustPaymentApi", [])
    .WithHttpEndpoint(env: "PAYMENT_API_PORT");

Node.js

JavaScript is well known as a front end language, but platforms like Node.js allow you to write server-side applications in JavaScript (and TypeScript) too. Aspire 13.0 introduces improved support for JavaScript apps via a new Aspire.Hosting.JavaScript package. This includes the ability to configure using pnpm or yarn package managers (the default being npm).

var nodeApp = builder.AddJavaScriptApp("node-joke-api", "../NodeApp", "start")
    .WithPnpm()
    // If you are using fnm for Node.js version management, you might need to adjust the PATH
    .WithEnvironment("PATH", Environment.GetEnvironmentVariable("PATH") + ";" + Environment.ExpandEnvironmentVariables(@"%USERPROFILE%\AppData\Roaming\fnm\aliases\default"))
    .WithHttpEndpoint(env: "PORT")
    .WithOtlpExporter();

I use fnm (Fast Node Manager) to manage my Node.js versions. This means that the actual node executable is not in the PATH by default, but rather is added (or updated) dynamically as I change directory via my PowerShell profile script. Because that script isn't run by Aspire, I explicity append the fnm default alias directory to the PATH environment variable so that node can be found.

Python

Python is an interesting ecosystem. There are a number of different package managers that will influence how you work with it. Aspire has first-class support for Python applications that use pip via the Aspire.Hosting.Python NuGet package. (See Python apps in Aspire for more details).

I recently worked on a client engagement where they were using uv with their Python applications. Aspire 13.0 now includes direct support for uv (via WithUv()) and uvicorn (with AddUvicornApp()):

var pythonApp = builder.AddUvicornApp("python-api", "../PythonUv", "src.api:app")
    .WithUv()
    .WaitFor(mongo)
    .WaitFor(rust)
    .WaitFor(nodeApp)
    .WithEnvironment("PYTHONIOENCODING", "utf-8")
    .WithEnvironment("MONGO_CONNECTION_STRING", new ConnectionStringReference(mongo.Resource, false))
    .WithEnvironment("PAYMENT_API_BASE_URL", new EndpointReference(rust.Resource, "http"))
    .WithEnvironment("NODE_APP_BASE_URL", ReferenceExpression.Create($"{nodeApp.Resource.GetEndpoint("http")}"))
    .WithHttpHealthCheck("/")
    .WithExternalHttpEndpoints();

We wait for the MongoDB service, the Rust payment service, and the Node.js joke service, so that they have all started before the Python app. We also set up environment variables to pass in the connection strings and endpoints that the Python app needs to connect to those services.

A Vite React Frontend web app

The same Aspire.Hosting.JavaScript package that we used to wire up the Node.js application can also be used for the frontend web app. Helpfully, it specifically includes support for Vite apps

var web = builder.AddViteApp("web", "../web-vite-react")
    .WithPnpm()
    // If you are using fnm for Node.js version management, you might need to adjust the PATH
    .WithEnvironment("PATH", Environment.GetEnvironmentVariable("PATH") + ";" + Environment.ExpandEnvironmentVariables(@"%USERPROFILE%\AppData\Roaming\fnm\aliases\default"))
    .WaitFor(pythonApp)
    .WithEnvironment("VITE_API_BASE_URL", new EndpointReference(pythonApp.Resource, "http"));

Again, because I use fnm to manage my Node.js versions, I need to append the fnm default alias directory to the PATH environment variable so that node can be found.

The frontend application only talks to the Python backend API, so we enusre that service has started first, and set up the VITE_API_BASE_URL environment variable so that the Vite app knows where to find the API.

And with that in place, we can run the entire distributed application locally with a single command:

dotnet run --project ./AspireAppHost/AspireAppHost.csproj --launch-profile http

Not all of the applications I'm using here support HTTPS self-signed development certificates, so I stick with running everything over HTTP for now. This is something that Aspire has improved on in 13.0. Obviously in a production deployment you'd want to use HTTPS everywhere. If I didn't need to set the launch profile, then I could use the Aspire CLI instead:

aspire run

The nice thing about all this is I didn't need to make any changes any of the front end or back end applications to get them to work with Aspire. All the configuration was done in the Aspire host application. This assumes that your applications have provided a 'seam' (eg. environment variables or command line arguments) to allow you to configure things like connection strings, ports, and endpoints.

Here's the final version of AppHost.cs:

var builder = DistributedApplication.CreateBuilder(args);

// MongoDB
var mongo = builder.AddMongoDB("mongo")
    .WithDataVolume()
    .WithMongoExpress();

var mongodb = mongo.AddDatabase("petstore");

var loadData = builder.AddExecutable("load-data", "pwsh", "../mongodb", "-noprofile", "./populate.ps1")
    .WaitFor(mongo)
    .WithArgs("-connectionString")
    .WithArgs(new ConnectionStringReference(mongo.Resource, false));
//.WithExplicitStart();

// Rust service
var rust = builder.AddRustApp("rustpaymentapi", "../RustPaymentApi", [])
    .WithHttpEndpoint(env: "PAYMENT_API_PORT");

// Node.js App
var nodeApp = builder.AddJavaScriptApp("node-joke-api", "../NodeApp", "start")
    .WithPnpm()
    // If you are using fnm for Node.js version management, you might need to adjust the PATH
    .WithEnvironment("PATH", Environment.GetEnvironmentVariable("PATH") + ";" + Environment.ExpandEnvironmentVariables(@"%USERPROFILE%\AppData\Roaming\fnm\aliases\default"))
    .WithHttpEndpoint(env: "PORT")
    .WithOtlpExporter();

// Python API
var pythonApp = builder.AddUvicornApp("python-api", "../PythonUv", "src.api:app")
    .WithUv()
    .WaitFor(mongo)
    .WaitFor(rust)
    .WaitFor(nodeApp)
    .WithEnvironment("PYTHONIOENCODING", "utf-8")
    .WithEnvironment("MONGO_CONNECTION_STRING", new ConnectionStringReference(mongo.Resource, false))
    .WithEnvironment("PAYMENT_API_BASE_URL", new EndpointReference(rust.Resource, "http"))
    .WithEnvironment("NODE_APP_BASE_URL", ReferenceExpression.Create($"{nodeApp.Resource.GetEndpoint("http")}"))
    .WithHttpHealthCheck("/")
    .WithExternalHttpEndpoints();

// Frontend
var web = builder.AddViteApp("web", "../web-vite-react")
    .WithPnpm()
    // If you are using fnm for Node.js version management, you might need to adjust the PATH
    .WithEnvironment("PATH", Environment.GetEnvironmentVariable("PATH") + ";" + Environment.ExpandEnvironmentVariables(@"%USERPROFILE%\AppData\Roaming\fnm\aliases\default"))
    .WaitFor(pythonApp)
    .WithEnvironment("VITE_API_BASE_URL", new EndpointReference(pythonApp.Resource, "http"));

builder.Build().Run();

To get the full benefit of Aspire you will want to take a look at adding OpenTelemetry instrumentation. If you already have that in place then there's probably nothing to change. Aspire will set a bunch of OpenTelemetry-related environment variables for each application. If that'a new thing then you'll get the double benefit of then being able to take advantage of that telemetry when your applications are deployed to production too!

Conclusion

Aspire has the potential to greatly simplify and improve the local development experience for distributed applications - potentially removing the need for numerous scripts and manual steps for a developer to get up and running much more quickly. It's also a tool that can benefit almost every development team, regardless of the technology stack they are using.

Introducing Aspire

2025-11-12T09:00:00.000+10:30

Aspire is a really interesting tool for orchestrating your local development experience, integrating with OpenTelemetry, and optionally providing a way to automate deployments. It has the potential to replace manual steps and custom startup scripts with a more declarative and simpler approach.

Originally known as '.NET Aspire', the name has recently been tweaked to just 'Aspire' to help promote it's applicability across all kinds of development environments, not just .NET.

Today the latest version of Aspire was demonstrated at .NET Conf 2025. Let's take a look at what Aspire is, and how it can help you.

The AppHost

At the heart of Aspire is the concept of an 'AppHost'. This is a .NET project in which you define the services (which could be local applications, containers and even remote services). You also define any dependencies between those services, and can use that to then provide configuration information (connection strings, endpoint URLs etc) so that they can communicate with each other. You're essentially creating a model of your application architecture.

Importantly, while the AppHost is a .NET project (possibly even a .NET 10 file-based application to make it really simple), this is the only thing that needs .NET. All the other services can be written in pretty much any language or framework you like. They could be Node.js applications, Python, Java, or anything else (including .NET of course!).

Here's an example AppHost file:

var builder = DistributedApplication.CreateBuilder(args);

var mongo = builder.AddMongoDB("mongo")
    .WithDataVolume();

var api = builder.AddProject<Projects.aspire_starter_ApiService>("apiservice")
    .WithReference(mongo)
    .WaitFor(mongo);

var frontend = builder.AddViteApp("frontend", "../frontend")
    .WithPnpm()
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

In just those ~15 lines of code, we're describing an application which has a MongoDB database, a .NET API service, and a Vite frontend web app:

We create a builder variable (an instance of IDistributedApplicationBuilder) that will then use to define and wire up the services.
The MongoDB database is hosted as a Docker container, with a data volume to persist data between runs.
The API service is a .NET project that references the MongoDB service and waits for it to be ready before starting.
The frontend is a Vite application that references the API service and exposes an HTTP endpoint.

With that in place, all you need to do is run this AppHost project (either with dotnet run or via the Aspire CLI with aspire run), and Aspire will figure out the order to start the services, then start them up while providing the requested configuration information.

WaitFor

The WaitFor method tells Aspire that this service should wait until the referenced service is in a 'running' state. Services may define health checks that Aspire will use to determine when a service is truly ready. SQL Server is a good example - where even though the main SQL Server process may have started, the database engine won't be ready immediately as there are a number of housekeeping tasks it needs to complete before all the databases become available for use.

WithReference

The WithReference method causes Aspire to inject environment variables into the service which provide a way for it to connect to the referenced service.

For the above code, the references to Mongo generate connection string environment variable of the form ConnectionStrings__mongo. The API service can use that environment variable to connect to the MongoDB database.

The reference to the API service generate environment variables APISERVICE_HTTP and APISERVICE_HTTPS which provide the URLs that the frontend can use to connect to the API.

There are overloads of WithReference that allow you to customise naming scheme of the environment variables, and if that isn't enough you can always add a custom environment variable with WithEnvironment.

The dashboard

One of the key features of Aspire is that you're not just left to wonder how things are going. A really cool dashboard is provided that gives you both the high-level overview of all your services, as well as being able to drill into specific service configuration and logs, and even see OpenTelemetry traces and metrics (if you have OpenTelemetry added to your services).

Clicking on the 'frontend' service shows the configuration that Aspire has provided to that service, including the environment variables that were injected:

View all the console output from services (or filter to just a specific service):

If your services are instrumented with OpenTelemetry, you can see structured logs, traces and metrics:

Aspire is resilient enough that for example if you forget to start Docker, it will let you know that services depending on that can't start.

The cool thing though is you don't need to restart Aspire. If you start Docker, Aspire will notice that it is now available, and will start the services that were waiting on it. You can see the status change in real-time in the dashboard as services become healthy. Note that the other services (which need to wait for Mongo) are not even started yet.

Publishing and deploying

Aspire can optionally prepare the application for deployment by 'publishing' parameterised assets. You can then 'deploy' those assets to a specific target environment.

Currently, the following deployment targets are supported:

Docker / Docker Compose
Kubernetes
Azure Container Apps
Azure App Services

Some service types may support these targets natively, while others may need additional configuration. There are also non-Azure targets available too. For example there's support for AWS with the Aspire.Hosting.AWS package. See https://github.com/aws/integrations-on-dotnet-aspire-for-aws for more information.

For example, adding this line to the AppHost above:

builder.AddDockerComposeEnvironment("aspire-starter");

and then running the publish command:

aspire publish

causes a docker-compose.yaml and .env files to be created:

services:
  aspire-starter-dashboard:
    image: "mcr.microsoft.com/dotnet/nightly/aspire-dashboard:latest"
    expose:
      - "18888"
      - "18889"
    networks:
      - "aspire"
    restart: "always"
  mongo:
    image: "docker.io/library/mongo:8.0"
    environment:
      MONGO_INITDB_ROOT_USERNAME: "admin"
      MONGO_INITDB_ROOT_PASSWORD: "${MONGO_PASSWORD}"
    expose:
      - "27017"
    volumes:
      - type: "volume"
        target: "/data/db"
        source: "aspire-starter.apphost-06ac3d63aa-mongo-data"
        read_only: false
    networks:
      - "aspire"
  apiservice:
    image: "${APISERVICE_IMAGE}"
    environment:
      OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES: "true"
      OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES: "true"
      OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY: "in_memory"
      ASPNETCORE_FORWARDEDHEADERS_ENABLED: "true"
      HTTP_PORTS: "${APISERVICE_PORT}"
      ConnectionStrings__mongo: "mongodb://admin:${MONGO_PASSWORD}@mongo:27017?authSource=admin&authMechanism=SCRAM-SHA-256"
      OTEL_EXPORTER_OTLP_ENDPOINT: "http://aspire-starter-dashboard:18889"
      OTEL_EXPORTER_OTLP_PROTOCOL: "grpc"
      OTEL_SERVICE_NAME: "apiservice"
    expose:
      - "${APISERVICE_PORT}"
    depends_on:
      mongo:
        condition: "service_started"
    networks:
      - "aspire"
networks:
  aspire:
    driver: "bridge"
volumes:
  aspire-starter.apphost-06ac3d63aa-mongo-data:
    driver: "local"

Just to repeat, the publish and deployment aspects of Aspire are entirely optional. If you've already got Infrastructure as Code and/or CI/CD pipelines you can continue to use those, and just use Aspire for local development. But if you haven't got them in place, Aspire may be useful to help you get started.

Learning more and getting started

Head over to the new home of Aspire at https://aspire.dev to find more details about how Aspire works and how to get started.

(There is also the old documentation site learn.microsoft.com/dotnet/aspire/, but as I understand it the plan is for that content to be gradually migrated to the new site)

Oh, and finally keep an eye out for my presentation happening as part of the 'Community' day of .NET Conf 2025 where I'll be showing how well Aspire works with non-.NET applications!

Clean up old .NET installs with the .NET Uninstall Tool

2025-10-17T11:30:00.000+10:30

New versions of .NET are released almost monthly with bug and security fixes. Visual Studio also will install specific versions of .NET SDKs. What this means is that over time you may end up with a lot of .NET SDKs and runtimes installed, some of which are redundant and just taking up disk space.

You could uninstall specific versions manually, or you could use the .NET Uninstall Tool.

On Windows if you're using Chocolatey, you can install the tool like this:

choco install dotnet-uninstaller

Or you can download the installer directly from https://github.com/dotnet/cli-lab/releases (there's also a Mac OS version available). That GitHub repository has the source for the tool too.

Here's what dotnet --info shows on my machine:

.NET SDK:
 Version:           10.0.100-rc.2.25502.107
 Commit:            89c8f6a112
 Workload version:  10.0.100-manifests.4d32cd9e
 MSBuild version:   18.0.0-preview-25502-107+89c8f6a11

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100-rc.2.25502.107\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.0-rc.2.25502.107
  Architecture: x64
  Commit:       89c8f6a112

.NET SDKs installed:
  3.1.426 [C:\Program Files\dotnet\sdk]
  6.0.428 [C:\Program Files\dotnet\sdk]
  8.0.318 [C:\Program Files\dotnet\sdk]
  8.0.415 [C:\Program Files\dotnet\sdk]
  9.0.205 [C:\Program Files\dotnet\sdk]
  9.0.305 [C:\Program Files\dotnet\sdk]
  9.0.306 [C:\Program Files\dotnet\sdk]
  10.0.100-rc.2.25502.107 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

I have Visual Studio 2022 and Visual Studio 2026 Insiders installed, and also used some of the Chocolatey packages to preinstall various SDK versions (and some runtimes may have been installed as dependencies of other software).

Ideally I'd just end up with the latest SDK for each major version. The Uninstall tool has a few different commands and combinations of options. First up let's see what the list command generates:

dotnet-core-uninstall list

This tool cannot uninstall versions of the runtime or SDK that are 
    - SDKs installed using Visual Studio 2019 Update 3 or later.
    - SDKs and runtimes installed via zip/scripts.
    - Runtimes installed with SDKs (these should be removed by removing that SDK).
The versions that can be uninstalled with this tool are:

.NET Core SDKs:
  9.0.306  x64    [Used by Visual Studio. Specify individually or use --force to remove]
  9.0.305  x64
  9.0.205  x64
  8.0.415  x64    [Used by Visual Studio 2022. Specify individually or use --force to remove]
  8.0.318  x64
  6.0.428  x64    [Used by Visual Studio 2022. Specify individually or use --force to remove]
  3.1.426  x64    [Used by Visual Studio 2019. Specify individually or use --force to remove]

.NET Core Runtimes:

ASP.NET Core Runtimes:

.NET Core Runtime & Hosting Bundles:

My goal is to remove 9.0.305, 9.0.205 and 8.0.318 SDKs, as I have newer versions of 8 and 9 already installed.

Before committing to removing anything, it's probably a good idea to make use of the whatif (aka dry-run) command first, just so you can confirm it is going to do what you thought.

First up, let's see what the --all-lower-patches filter does:

dotnet-core-uninstall whatif --all-lower-patches --sdk

*** DRY RUN OUTPUT
Specified versions:
  Microsoft .NET SDK 9.0.305 (x64)
*** END DRY RUN OUTPUT

Interesting - that's a good start, but it doesn't include the other two SDKs.

What about --all-but-latest?

dotnet-core-uninstall whatif --all-but-latest --sdk

*** DRY RUN OUTPUT
Specified versions:
  Microsoft .NET SDK 9.0.305 (x64)
  Microsoft .NET SDK 9.0.205 (x64)
  Microsoft .NET SDK 8.0.318 (x64)
*** END DRY RUN OUTPUT

That looks good! Let's do this..

dotnet-core-uninstall remove --all-but-latest --sdk --yes

Uninstalling: Microsoft .NET SDK 9.0.305 (x64).
Uninstalling: Microsoft .NET SDK 9.0.205 (x64).
Uninstalling: Microsoft .NET SDK 8.0.318 (x64).

And there you go!

Here's what dotnet --info produces now:

.NET SDK:
 Version:           10.0.100-rc.2.25502.107
 Commit:            89c8f6a112
 Workload version:  10.0.100-manifests.4d32cd9e
 MSBuild version:   18.0.0-preview-25502-107+89c8f6a11

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100-rc.2.25502.107\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.0-rc.2.25502.107
  Architecture: x64
  Commit:       89c8f6a112

.NET SDKs installed:
  3.1.426 [C:\Program Files\dotnet\sdk]
  6.0.428 [C:\Program Files\dotnet\sdk]
  8.0.415 [C:\Program Files\dotnet\sdk]
  9.0.306 [C:\Program Files\dotnet\sdk]
  10.0.100-rc.2.25502.107 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

That looks better. I can see there is still a 9.0.9 runtime that might be a candidate to be removed given there's also a 9.0.10. That specific runtime was originally installed as a Chocolatey package dependency, so I expect that will be resolved when the package that depends on that runtime version gets upgraded.

Verify.Cli - Snapshot testing without tests

2025-07-28T07:00:00.000+09:30

In my last post, I looked at using the Verify library to implement snapshot testing in .NET unit tests.

I've been doing quite a lot of 'DevOps' work in recent years, and a large part of that has involved creating and optimising build and deployment (CI/CD) pipelines. Not infrequently I've wanted to add a sanity check to a pipeline to ensure a file has the correct content. "Oh if only I could call Verify from my pipeline", I'd think.

If the file was in version control, I could sometimes fallback to relying on git diff to tell if the file had changed. But if it was a generated file that technique wouldn't work. Other file comparison tools (like regular diff) might help, unless you had things like timestamps or other elements in the file that you wanted to ignore for the comparison. This is all bread and butter for Verify.

And so I created Verify.Cli!

Verify.Cli

Verify.Cli is a command-line tool that uses Verify internally. But while Verify was originally written to be used in unit tests, it is possible to host it in a console application and get similar functionality. It can be used to perform snapshot testing on an individual file.

You can install Verify.CLI as a .NET global tool, or there's a Docker image so you can run it from a container.

Case study - feed.xml

I've recently rebuilt my blog using Astro. It generates a static website, but there is a challenge. Astro and the other libraries that are used to build my blog are updated frequently. It would be great to have confidence that those updates are not breaking the site. If it was a regular software application I could write some unit or integration tests. Given it generates static files, then the idea of snapshot testing some specific files would be helpful.

The feed.xml file is created when you run pnpm build in the dist folder. Here's part of it:

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-AU" xmlns:media="http://search.yahoo.com/mrss/">
  <id>https://david.gardiner.net.au/feed.xml</id>
  <title type="html">David Gardiner</title>
  <updated>2025-07-26T10:39:59.564Z</updated>
  <subtitle>A blog of software development, .NET and other interesting things</subtitle>
  <generator uri="https://github.com/flcdrg/astrojs-atom" version="1.0.48">astrojs-atom</generator>
  <author>
    <name>David Gardiner</name>
  </author>
  <link href="https://david.gardiner.net.au/feed.xml" rel="self" type="application/atom+xml"/>
  <link href="https://david.gardiner.net.au/" rel="alternate" type="text/html" hreflang="en-AU"/>
  <entry>
    <id>https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression</id>
    <updated>2025-07-14T08:00:00.000+09:30</updated>
    <title>Azure Pipelines template expressions</title>
    <link href="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression" rel="alternate" type="text/html" title="Azure Pipelines template expressions"/>
    <category term="Azure Pipelines"/>
    <published>2025-07-14T08:00:00.000+09:30</published>
    <summary type="html">
      <![CDATA[Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions
and see some common examples of their usage.]]>
    </summary>
    <content type="html" xml:base="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression">
      <![CDATA[<p>In my <a href="/2025/06/azure-pipeline-conditionals">last post</a> I wrote about using custom conditions in Azure Pipelines to evaluate whether to skip a step, job or stage at runtime.</p>
<p>Sometimes we can do better though. With template expressions we can not just skip something, we can remove it entirely. We can also use it to optionally insert values in a pipeline (something you can't do with runtime custom conditions).</p>
<p>The important thing to remember is that template expression are a "compile time" feature. They can only operate on things that are available at compile time. <a href="https://learn.microsoft.com/azure/devops/pipelines/process/set-variables-scripts?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655">Variables set by scripts</a>, and <a href="https://learn.microsoft.com/azure/devops/pipelines/process/variables?view=azure-devops&amp;tabs=yaml%2Cbatch&amp;WT.mc_id=DOP-MVP-5001655#use-output-variables-from-tasks">task output variables</a> are two examples of things that are not available at compile time.</p>
<p>Compare these two Azure Pipeline runs. The first uses custom conditions to decided if the 'Publish Artifact' step is executed or not. Notice the 'Publish Artifact' step is listed, but the icon shown is a white arrow (rather than green tick)
<img src="https://david.gardiner.net.au/_astro/azure-pipelines-custom-conditions.Be6IaBQz_101Uki.webp" alt="Job showing a step 'Publish Artifact' that was conditionally not executed" /></p>
<p>If we use a template expression, then if it evaluates to false then the step is not even included in the job!</p>
<p><img src="https://david.gardiner.net.au/_astro/azure-pipelines-template-expressions.kRV13og-_2f5chf.webp" alt="Job without a 'Publish Artifact' step " /></p>
<p><a href="https://learn.microsoft.com/azure/devops/pipelines/process/template-expressions?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655">Template expressions</a> use the syntax <code>${{ }}</code></p>
<p>You can reference <code>parameters</code> and <code>variables</code> in template expressions. The latter are only variables that are defined in the YAML file and most of the <a href="https://learn.microsoft.com/azure/devops/pipelines/build/variables?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655">predefined variables</a>. (That page does list which variables can be used in template expressions, but you may need to scroll the page to the right to see that column!)</p>
<p>You can't reference variables that are created by scripts or anything else that is only available at runtime.</p>
<p>You can use <a href="https://learn.microsoft.com/azure/devops/pipelines/process/expressions?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655#functions">general functions</a> (the same ones we used previously with runtime Custom Conditions) in template expressions, as well as two special <a href="https://learn.microsoft.com/azure/devops/pipelines/process/template-expressions?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655#template-expression-functions">Template expression functions</a>.</p>
<h2>Common patterns</h2>

We run the Verify CLI against this file like this (after creating a verified directory )

verify --file ./dist/feed.xml --verified-dir verified

Because there is no existing verified/feed.xml.verified.xml file, the Verify library launches Beyond Compare (my diff tool of choice) and I can use it to create the verified file.

However if I rebuild the site again and re-run verify, it shows up a difference. It turns out that the <updated>2025-07-26T10:39:59.564Z</updated> line is updated each time! Happily Verify's scrubbers can handle timestamps like that.

If we were using Verify in a unit test, we'd configure this scrubber using VerifySettings.ScrubInlineDateTimes(). The equivalent for the command-line tool is --scrub-inline-datetime. If we run verify again using this:

verify --file dist/feed.xml --verified-dir verified --scrub-inline-datetime "yyyy-MM-ddTHH:mm:ss.fffZ"

We'll see that the scrubber has replaced the timestamp with a placeholder:

  <updated>DateTime_1</updated>

With that in place we can repeat the validation with subsequent builds and be sure that the file should be equivalent. If the comparison ever fails in the future then we can be pretty confident it's caused by a change in our logic or an update to one of the libraries.

Here's how I'm using Verify.Cli in a GitHub Action workflow:

- name: Setup .NET
  uses: actions/setup-dotnet@v5
  with:
    dotnet-version: 9.x

- name: Install Verify.Cli
  run: dotnet tool install --global Verify.Cli

- name: Verify
  run: |
    verify --file dist/feed.xml --verified-dir verified --scrub-inline-datetime "yyyy-MM-ddTHH:mm:ss.fffZ"

Case study - blog post

The other thing I was keen to keep an eye on was individual blog posts. Here's part of one:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <link rel="icon" href="/favicon.ico">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="generator" content="Astro v5.12.0">
    <link rel="canonical" href="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression">
    <meta name="description" content="Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions
and see some common examples of their usage."><meta name="og:description" content="Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions
and see some common examples of their usage."><meta name="og:title" content="Azure Pipelines template expressions"><meta name="og:type" content="article"><meta name="og:url" content="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression"><meta name="og:image" content="/_astro/azure-pipelines-logo.B45UakAg.png"><meta name="og:image:width" content="80"><meta name="og:image:height" content="80"><meta name="og:image:alt" content="Azure Pipelines logo"><script type="application/ld+json">{"@context":"https://schema.org","@type":"BlogPosting","mainEntityOfPage":{"@type":"WebPage","@id":"https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression"},"headline":"Azure Pipelines template expressions","description":"Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions\nand see some common examples of their usage.","image":"/_astro/azure-pipelines-logo.B45UakAg.png","author":{"@type":"Person","name":"David Gardiner","url":"https://david.gardiner.net.au/"},"datePublished":"2025-07-14T08:00:00.000+09:30"}</script>
    <title>Azure Pipelines template expressions</title>
    
  <link rel="stylesheet" href="/_astro/_slug_.CT3ttAlr.css"></head>
  <body>
    <header>
      <nav>
        <div class="nav-container" data-astro-cid-pux6a34n>

Most of that should be pretty stable. I tried a similar approach to what I used for feed.xml, and created a pull request then ran it in the GitHub Actions workflow... and it failed!

When I looked closer I realised that I've configured pull request build to use pnpm build --devOutput, whilst main branch builds just use pnpm build.

One difference with the former is that it adds an extra attribute to <img> elements - data-image-component="true". To be able to compare files we'll need to remove all instances of that.

Verify.Cli has the --scrub-inline-remove parameter that we can use for that. eg.

--scrub-inline-remove ' data-image-component="true"'

When Astro processes images, it does appear to generate pretty stable URLs, but just in case it might be best to exclude those as well. Here's a typical img tag:

<img src="/_astro/MVP_Logo_Horizontal_Preferred_Cyan300_RGB_300ppi.a-4xiaYx_2bYEEr.png"

These are not fixed strings - they are unique for each image, so using a regular expression would make sense. This time we'll use --scrub-inline-pattern with an appropriate expression:

--scrub-inline-pattern '(?<prefix>")/_astro/[^"]+(?<suffix>")'

This parameter has an extra feature that I'm taking advantage of. If you include named groups in the regular expression 'prefix' and or 'suffix', then the scrubber will add those back to the start and end. I'm using that so that the double quotes are maintained.

The replacement looks like this:

<img src="STRING_5"

Here's the full command:

verify --file dist/2025/07/azure-pipeline-template-expression.html --verified-dir verified --scrub-inline-pattern '(?<prefix>")/_astro/[^"]+(?<suffix>")' --scrub-inline-remove ' data-image-component="true"'

In this case, the GitHub Action workflow is using the Docker image to run Verify.Cli (another way of using it instead of installing it as a .NET global tool):

- name: Verify post
  run: docker run --rm --user "$(id -u):$(id -g)" -v $PWD:/tmp flcdrg/verify-cli --file /tmp/dist/2025/07/azure-pipeline-template-expression.html --verified-dir /tmp/verified --scrub-inline-pattern '(?<prefix>")/_astro/[^"]+(?<suffix>")' --scrub-inline-pattern '(?<prefix>title=")[^"]+(?<suffix>")' --scrub-inline-remove ' data-image-component="true"' --scrub-inline-pattern '(?<prefix>meta name="generator" content="Astro v)[\d\.]+(?<suffix>")' --verbosity detailed

What if it fails?

If Verify.Cli fails locally on your machine, you can quickly identify the conflict via your visual diff tool of choice. But if it fails in a pipeline, then currently all you get is an error that the files are different. For now, I've come up with a hacky workaround:

- name: Diff files if error
  if: failure()
  run: |
    diff -u dist/feed.xml verified/feed.xml.verified.xml

This step in the workflow only runs if the Verify.Cli step failed. It assumes you have the diff tool installed on your build agent. This could be an aspect to improve in Verify.Cli in the future.

Conclusion

Take a look at https://github.com/flcdrg/astro-blog-engine for a repo making use of Verify.Cli (including the main workflow).

If you have a need to use the snapshot testing technique on individual files outside of unit tests, please give Verify.Cli a go. Let me know in the comments what you think, and feel free to submit any suggestions or bug reports over at the repo.

Helmet by Leonidas Oikonomou from Noun Project (CC BY 3.0)

Snapshot testing .NET code with Verify

2025-07-21T20:00:00.000+09:30

Snapshot testing has become a really popular way of asserting data has the correct shape and values in software unit tests. My first introduction to these kinds of tests was with ApprovalTests for .NET. You may also have encountered them in JavaScript with Jest. But in my opinion the standout library for snapshot testing is Simon Cropp's excellent Verify.

I've written previously about Verify, specifically an extension I created for Verify to facilitate snapshot testing with MongoDB. One thing that sets Verify apart is the ability to customise and configure how it works for each test, particularly in the way it serialises and sanitises/scrubs the data.

Data scrubbing (see Scrubbers) is how you deal with values that may change between unit test runs, but within a run they must be consistent. You can choose to either remove values entirely, or replace them with special placeholders.

For example, consider the following C# code that creates a dynamic JSON object:

var json = new
{
    id = Guid.NewGuid(),
    time = DateTimeOffset.Now,
    name = "David Gardiner",
    currentUser = Environment.UserName
};

var text = System.Text.Json.JsonSerializer.Serialize(json);

var settings = new VerifySettings();
settings.ScrubUserName();

// Ensure received and verified files have .json suffix (otherwise it will be .txt)
settings.UseStrictJson();

return VerifyJson(text, settings);

The actual value of the JSON object will change every time the code is run, as it includes values like a random GUID, the current date and time, and the current username. If you just compared a file that you'd serialised this object to, then it wouldn't match if you compared it again a few seconds later.

Instead, by the use of scrubbers and sanitisers, you end up with a file like this:

{
  "id": "Guid_1",
  "time": "DateTimeOffset_1",
  "name": "David Gardiner",
  "currentUser": "TheUserName"
}

Notice that the GUID, time and current user values have all been replaced with placeholders names. The clever thing is that if you had other properties with the same original values, then Verify is smart enough to swap those all over too (so you could easily confirm that Guid_1 was used in all the right places).

This means that your test will continue to pass if you run it 5 seconds later, or if you run it on a build server on the other side of the world with a different process username.

The underlying values will have changed, but the shape and usage of them hasn't, and that's what you care about.

There's a default set of scrubbers and sanitisers that you get out of the box, but you can enable additional ones or write your own. In the example above I opted in to username scrubbing by calling ScrubUserName().

If necessary, you can adjust how Dates and GUIDs are handled. There's even more options in Serializer Settings and Scrubbers.

Snapshot tests dramatically simplify your unit tests - the alternative would be lots of specific property asserts, which can get pretty messy.

The other aspect of Verify that really shines is how it can integrate with any of a number of popular GUI diff tools when you're running it interactively and a comparison fails.

In that scenario, it will automatically launch your diff tool (Beyond Compare is my diff tool of choice) showing you the actual and expected (verified) text and you can easily identify if the failure represents a bug that needs to be fixed, or alternatively it might be an expected change so you can easily update the verified content.

It's worth noting that Verify is smart enough to realise when it is running non-interactively (like on a build server), and in that case it just reports the comparison failed, causing the related unit test to fail. No GUI diff tools are launched.

In my next post I'll show how I took Verify and found a way to use it outside of unit tests.

Side note: The code samples in this blog post were included by using one of Simon's other projects - https://github.com/SimonCropp/MarkdownSnippets. A really clever tool for embedding code samples in Markdown files, which has the advantage that the code samples are more likely to be valid code as you can compile the original source files

Helmet by Leonidas Oikonomou from Noun Project (CC BY 3.0)

David Gardiner - .NET

.NET Azure Function error - A connection string was not found

Fatal error 0x8013132d debugging .NET 10 applications in Visual Studio

Exceptional unit tests

Best of C# 14 - extension members

Possible reasons for not using an extension block

Best of C# 14 - field keyword

Under the hood

Reasons for not using field

Aspire with Python, React, Rust and Node apps

MongoDB

Rust

Node.js

Python

A Vite React Frontend web app

Conclusion

Introducing Aspire

The AppHost

WaitFor

WithReference

The dashboard

Publishing and deploying

Learning more and getting started

Clean up old .NET installs with the .NET Uninstall Tool

Verify.Cli - Snapshot testing without tests

Verify.Cli

Case study - feed.xml

Case study - blog post

What if it fails?

Conclusion

Snapshot testing .NET code with Verify

Possible reasons for not using an `extension` block

Reasons for not using `field`