David Gardiner - Aspire

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>

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!