Next-gen SQL Projects with Microsoft.Build.Sql

SQL development is evolving fast, and Microsoft.Build.Sql is leading the charge. This next-generation SDK brings flexible project structures, better source control integration, automated build-time validation, and streamlined deployments with Azure DevOps and GitHub Actions -- helping teams manage database changes as seamlessly as application code.

To help developers get up to speed, Microsoft's Drew Skwiers-Koballa will present "Next-gen SQL Projects with Microsoft.Build.Sql" at the big Visual Studio Live! @ Microsoft HQ happening Aug. 4-8 at the company's campus in Redmond, Wash. His session will show how to modernize database workflows, improve code quality, and integrate database updates into full DevOps pipelines.

Ahead of the conference, we caught up with Skwiers-Koballa to learn more about Microsoft.Build.Sql, migration strategies, and what's coming next.

VisualStudioMagazine: What inspired you to present a session on this topic?
Skwiers-Koballa: The SQL projects capabilities for interacting with database deployments aren't new as a concept, but we just released the v1 of a project SDK that introduces improvements and simply, we're not done.

With more updates to the Visual Studio interface for SQL projects coming up and an immediate iteration to v2 of the Microsoft.Build.Sql SDK, there's new ways to increase your confidence in database changes.

How does Microsoft.Build.Sql enhance the management and deployment of SQL projects compared to traditional methods?
The Microsoft.Build.Sql SDK v1 introduces package references and a more flexible project format to SQL projects, meaning that you can quickly generate a SQL project from any source through automation and manage relationships in complex environments more easily.

Creating database objects and being able to deploy them is common functionality for a library with ORM functionality like EF Core, but being able to provide a dynamic script and analysis of the impact of the deployment specific to an environment is part of the SqlPackage CLI for SQL projects. You can continue with active EF Core development while benefiting from the deployment management through SQL projects by including the automatic generation of a SQL project as part of continuous integration for your app components.

What are the key benefits of using Microsoft.Build.Sql for version control in SQL development?
In addition to the deployment benefits from SQL projects, Microsoft.Build.Sql projects represent each database object as an individual SQL script. Your database is now a human-readable definition in source control, just like your application code. In your source control system the advantages of branching, commit history, and PR reviews now also apply to your database code by increasing the visibility to what is being changed, when it is being changed, and why it was changed.

What considerations should be taken into account when migrating existing SQL projects to utilize Microsoft.Build.Sql?
To convert an existing SQL project to Microsoft.Build.Sql, you should absolutely create a backup of the project file -- this is the only file that's changed during the migration. If you're migrating in either direction, you should know about a command-line tool called "DacpacVerify." This dotnet tool compares two dacpacs to confirm that the SQL project build artifacts match, a sign that the conversion was completed correctly.

If you're migrating an existing SQL project to the Microsoft.Build.Sql SDK you will benefit from the better compatibility of the project between VS Code and Visual Studio, but you need to be aware that the Visual Studio components are in preview. Each Visual Studio release brings new features and we're excited to complete the support for Microsoft.Build.Sql in Visual Studio soon.

Can you discuss any performance improvements observed when using Microsoft.Build.Sql in large-scale SQL projects?
As a piece of a DevOps toolkit, Microsoft.Build.Sql projects enable database and people efficiencies. Visibility to database changes in a pull request review enables a team to catch database design issues before they land in active environments, protecting the database workload from issues that can be quickly noticed like a table without indexes. You aren't on your own with SQL projects, because code analysis in SQL projects has access to the entire object model and can point out issues like inserting a 100-character variable into a 75-character column.

Concretely, Microsoft.Build.Sql projects support building with .NET 8+, so your database component can be built with the same Linux pipeline hosts as the rest of your app with the usual performance gain of a Linux pipeline. If you deconstruct a large database into multiple SQL projects, each piece can be updated on different cadences and made available on package feeds instead of built as a single project monolith. The build time varies based on the pieces to be updated and can significantly reduce the amount of time a developer waits for their changes to validate as part of code check-in.

Can you discuss any new features or planned improvements for Microsoft.Build.Sql that developers should watch for?
Watch for improvements in the Azure DevOps and GitHub integration for Microsoft.Build.Sql as well as the introduction of support for SQL Server 2025 with JSON and VECTOR types.

What resources can attendees use to learn more about this topic and prepare for your session?
Head over to aka.ms/sqlprojects for documentation that spans from getting started tutorials to in-depth reference information.

Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $400 when you register by the June 6 Super Early Bird deadline" said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.

Posted by David Ramel on 04/29/2025