ASP.NET Core与SQL Server数据库定向dacpac无冗余创建方案及GitHub Actions构建失败问题求助

Fixing the GitHub Actions Build Error (MSB3202) #

First, let's tackle the immediate build failure you're facing. The root cause of the "uninstalled SQL project still being referenced" issue lies in how Visual Studio handles project uninstalls and how MSBuild parses solution files:
When you uninstall a project in Visual Studio, it only comments out the project entry in the .sln file, but often leaves residual configuration entries in the GlobalSection(ProjectConfigurationPlatforms) section. MSBuild (used by the GitHub Runner) still picks up these leftover entries and tries to resolve the missing project file, triggering the MSB3202 error.

Here are three reliable fixes:

1. Manually clean up the solution file
   Open your .sln file in a text editor, and delete all references to Database-Proj.sqlproj:

   • Remove any commented lines starting with # Project("{...}") = "Database-Proj", "Database-Proj.sqlproj", "{...}"
   • Delete all entries under GlobalSection(ProjectConfigurationPlatforms) that reference the SQL project's GUID
     Save the file, push it to GitHub, and the build will stop looking for the uninstalled project.

2. Build only the Web project in CI
   Instead of building the entire solution in your GitHub YAML workflow, target the ASP.NET Core project directly. Replace your build command from:

   - run: dotnet build YourSolution.sln --configuration Release
   

   To:

   - run: dotnet build ./YourWebProject/YourWebProject.csproj --configuration Release
   

   This completely bypasses any unwanted project references in the solution file.

3. Disable build for the SQL project in solution settings
   If you want to keep the SQL project in the solution for local dacpac generation but prevent it from being built:

   • Right-click your solution in Visual Studio → Properties
   • Go to Configuration Properties → Configuration
   • Find your SQL project in the list, uncheck the Build box for all configurations (Debug/Release)
     Save the changes, push the solution file, and the GitHub Runner will ignore the SQL project during builds.

Better Workflow for Generating Targeted Dacpacs (No Redundancy) #

Now, for creating dacpacs without cluttering your Web solution, here are a few optimized approaches:

Option 1: Use SqlPackage.exe Command Line (No SQL Project Needed) #

You can generate a targeted dacpac directly from your database using the SQL Server Data Tools (SSDT) command-line tool, eliminating the need for a SQL project entirely:

1. Install SSDT on your local machine (it's included with Visual Studio, or you can download the standalone version)
2. Run this command to extract a dacpac (adjust connection string and paths as needed):

   sqlpackage.exe /Action:Extract /SourceConnectionString:"Server=YOUR_SERVER;Database=YOUR_DB;Integrated Security=True" /TargetFile:"C:\Path\To\YourDB.dacpac" /ExtractTarget:SchemaAndData
   

   • Use /ExtractTarget:Schema if you only need the database schema (no data)
   • Add /p:ExtractAllTableData=false to exclude specific tables if needed
3. You can even automate this in a separate CI job if you have a staging database, so you don't need to generate the dacpac locally.

Option 2: Separate Solutions for Web and Database #

Create two distinct solution files:

• One solution (WebSolution.sln) that only includes your ASP.NET Core project (for CI and daily development)
• A second solution (DatabaseSolution.sln) that includes the SQL project (only used when you need to generate or update the dacpac)
  This keeps your Web project's CI pipeline clean, and you only use the database solution when working on database changes.

Option 3: Switch to Entity Framework Core Migrations (Alternative to Dacpacs) #

If your project uses EF Core, consider using migrations instead of dacpacs for database updates:

• Migrations are code-first, so they integrate directly with your Web project
• You can run migrations automatically in CI using dotnet ef database update
• They provide more granular control over database changes (you can edit migration files if needed)
• No need for SSDT or SQL projects, reducing tooling overhead

内容的提问来源于stack exchange，提问作者Dave