Introducing .NET Support

By: Michael R. Bagnall

Last Updated: March 30, 2026

It has been a long time coming, and we are happy to say it is here: Probo.CI now supports .NET and ASP.NET applications. If your team writes C#, you can spin up a complete, throwaway environment for every pull request, application and database together, from a handful of lines in your .probo.yaml.

Pick Your Version

Probo supports .NET 6 through 10. You name the one you want at the top of your configuration, and Probo has the matching SDK ready before your build starts:

type: dotnet
dotnet: 9

That is the whole story on versions. Planning a move from 8 to 10? Open a branch, change one number, and let the two environments sit next to each other while you compare them.

You do not need a separate configuration file for that branch, either. Any step accepts a branches or skipBranches key, so a single .probo.yaml can do one thing on your upgrade branch and something else everywhere else:

type: dotnet
dotnet: 10

steps:
  - name: Setup .NET Web Site
    plugin: Dotnet
    subDirectory: app
    configuration: Debug
    skipBranches:
      - 'upgrade/*'

  - name: Setup .NET Web Site For Upgrade Review
    plugin: Dotnet
    subDirectory: app
    configuration: Release
    branches:
      - 'upgrade/*'

A * matches a whole family of branches, so upgrade/* covers upgrade/net10, upgrade/spike, and anything else you open under that name. The rest of the rules are on the Restricting Build Steps by Branch page.

A Minimal Build

Here is everything you need to get a .NET application building and serving:

type: dotnet
dotnet: 9
database: mssql:17

steps:
  - name: Setup .NET Web Site
    plugin: Dotnet
    subDirectory: app
    environment:
      DB_HOSTNAME: localhost
      DB_DATABASE: my_database
      DB_USERNAME: sa
      DB_PASSWORD: my_password
    configuration: Debug

The Dotnet plugin restores your dependencies, builds the project it finds, and starts it up. subDirectory is the one setting you always need to supply. It tells Probo where in your repository the application lives, relative to the root of the git repository.

The configuration value is the .NET build configuration, Debug or Release. On a review environment, Debug is often the friendlier choice, since a reviewer clicking around gets a real error page instead of a shrug.

Handing Settings to Your Application

Real applications need connection strings, service endpoints, and feature flags. The environment block passes those to your application as environment variables. Leave the values unquoted, since Probo applies the right quoting for you, and use apostrophes if you need them. Probo also passes along all of its own build variables, so your application can tell which branch and which pull request it is serving.

SQL Server, Included

Most .NET teams are on SQL Server, so that is the default we reach for. Setting database: mssql:17 starts a SQL Server 2025 instance inside your build, listening on localhost at port 1433.

Bringing your own data is the part people usually ask about first. SQL Server exports to a .bacpac file that carries schema and data together, and it does not use the same import shortcuts as MySQL or PostgreSQL. Instead you import it yourself with sqlpackage, which is already installed in every .NET build:

steps:
  - name: Decompress the .bacpac Database
    plugin: Shell
    command: gunzip -k $ASSET_DIR/mydatabase.bacpac.gz

  - name: Import the .bacpac Database
    plugin: Script
    script: |
      sqlpackage /Action:Import \
      /SourceFile:"$ASSET_DIR/mydatabase.bacpac" \
      /TargetServerName:"localhost" \
      /TargetDatabaseName:"MyDatabase" \
      /TargetUser:"sa" \
      /TargetPassword:"Password77^^" \
      /TargetTrustServerCertificate:True

Put those steps ahead of your Dotnet step and the database is fully populated by the time your application starts. The complete walkthrough, including how to produce the .bacpac in the first place, lives on the Importing a .bacpac File page.

If your stack does not run on SQL Server, you are not stuck with it. Any of our available databases will work with a .NET build.

The Rest of Your Stack

A .NET application is rarely alone in the repository. If your front end compiles with Node, ask for Node. If you search with Solr, attach a core. It all goes in the same file:

type: dotnet
dotnet: 9
nodejs: 24
database: mysql:8.4

assets:
  - solr8.zip

solr:
  name: solr
  version: 8
  core_archive: solr8.zip
  core_folder: MyApp8
  compression: zip

The only things you cannot add to a .NET build are php and python. Everything else in the Probo toolbox is fair game.

Get Started

Every plugin option and its default is documented on the .NET Usage & Configuration page. Drop a type: dotnet block into your .probo.yaml, push a branch, and your next pull request arrives with a running environment attached.

If you get stuck, or if there is something in the .NET world you would like us to support, let us know. We read every message.

Related Articles & Information

---

.NET Usage & Configuration Importing a .bacpac File Database Configuration