Importing a .bacpac File

Microsoft SQL Server databases are exported and imported as .bacpac files - a self-contained package holding both schema and data. Unlike MySQL, MariaDB, and PostgreSQL, SQL Server does not use a Probo.CI helper import. There is no database:/databaseGzipped: shortcut on the Dotnet plugin for a .bacpac. Instead, you import it yourself with the sqlpackage command, which is available natively in every .NET build.

This page walks through importing a .bacpac into the SQL Server instance that Probo.CI provisions for your build.

How It Fits Together

When you set database: mssql:17 in your .probo.yaml, Probo.CI installs and starts a Microsoft SQL Server daemon inside your build container. It listens on localhost (port 1433) and is reachable with the sa account:

Your job is to get the .bacpac into that server, then point your application at the database you created.

Preparing Your .bacpac

Export your source database to a .bacpac. From an existing SQL Server you can use sqlpackage locally, or export from SQL Server Management Studio (Tasks → Export Data-tier Application):

sqlpackage /Action:Export \
  /SourceServerName:"your-server" \
  /SourceDatabaseName:"YourDatabase" \
  /TargetFile:"mydatabase.bacpac"

Then compress it with gzip and commit it, or otherwise make it available, as a build asset:

gzip mydatabase.bacpac        # produces mydatabase.bacpac.gz

The Build Configuration

A complete .probo.yaml looks like this: request a mssql database, add the compressed .bacpac as an asset, import it with a Script step, and then build and run your application with the Dotnet plugin.

type: dotnet
dotnet: 9
database: mssql:17

assets:
  - mydatabase.bacpac.gz

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

  - name: Setup .NET Web Site
    plugin: Dotnet
    subDirectory: app
    environment:
      DB_HOSTNAME: localhost
      DB_DATABASE: MyDatabase
      DB_USERNAME: sa
      DB_PASSWORD: Password77^^
    configuration: Debug

The import runs before the Dotnet step so the database is fully populated by the time your application starts.

Understanding the sqlpackage Flags

The /TargetDatabaseName you choose here is the database name your application must connect to - keep it consistent with the environment variables on your Dotnet step (DB_DATABASE above).

Wiring Up Your Application

Pass the connection details to your application through the Dotnet plugin’s environment block, as shown above. How your code reads those values is up to you - a typical ASP.NET connection string built from them would be:

Server=localhost;Database=MyDatabase;User Id=sa;Password=Password77^^;TrustServerCertificate=True;

Using sqlpackage Outside a .NET Build

The sqlpackage command ships with the .NET build image, so the steps above work out of the box for dotnet builds. If you need to import a .bacpac in a non-.NET build (for example a php or nodejs build that talks to mssql), install the .NET SDK and the tool first, then run the same import:

steps:
  - name: Install sqlpackage
    plugin: Script
    script:
      - dotnet tool install --global microsoft.sqlpackage
      - export PATH="$PATH:$HOME/.dotnet/tools"

Everything after installation - the /Action:Import invocation and the connection details - is identical to the .NET example above.

Related Articles & Information

---

Build Steps Database Configuration