Azure Data Studio发布SQL项目失败：dotnet build返回0但未触发发布

问题背景 #

该数据库项目最初由SSDT创建，在Visual Studio 2019（版本16.11.20）中构建正常，输出如下：

Build started...
------ Build started: Project: Database Extract, Configuration: Debug Any CPU ------
        Database Extract -> C:\Users\Peter\Source\Repos\Azure DWH\Azure DWH\Database Extract\bin\Output\Database_Extract.dll
        Database Extract -> C:\Users\Peter\Source\Repos\Azure DWH\Azure DWH\Database Extract\bin\Output\Database Extract.dacpac
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

但使用Azure Data Studio（ADS）的SQL Database Projects扩展发布同一.sqlproj文件时，构建虽完成（产生127条列和表大小写引用警告），却提示dotnet build返回代码0且发布任务未启动。通过ADS基于现有数据库创建的新项目可正常发布，需保留旧.sqlproj文件继续使用。

已尝试的操作：

• 检查系统.NET SDK版本（含1.04、3.1.426、5.0.408等）
• 修复.NET SDK并指定ADS的SDK路径
• 安装旧版本SQL Database Projects扩展
• 在VSCode中执行相同操作，得到相同错误
• 更新nuget.config文件
• 完全重装ADS

问题分析 #

1. SSDT旧项目与ADS扩展的配置兼容性问题：SSDT创建的.sqlproj文件使用旧版MSBuild目标、属性或NuGet包（如Microsoft.Data.Tools.Msbuild），与ADS依赖的dotnet SDK构建逻辑不匹配，导致构建完成后无法触发发布流程。
2. 构建输出或产物路径不匹配：旧项目的OutputPath、DacPacOutputPath配置可能不符合ADS扩展的预期，导致扩展无法找到生成的dacpac文件，从而跳过发布。
3. 大小写警告的潜在干扰：虽然大小写引用警告为非致命，但可能触发扩展内部的异常判断逻辑，中断发布流程；同时也反映项目对象命名不符合Azure SQL Database的规范，可能间接影响兼容性。
4. .NET SDK版本适配问题：ADS的SQL Database Projects扩展通常依赖较新版本的.NET SDK（如.NET 6+），旧项目指定的目标框架或依赖的SDK版本过低，导致构建后无法触发后续发布步骤。

解决方案方向 #

1. 同步项目配置至ADS兼容格式 #

• 新建一个ADS数据库项目，对比其.sqlproj文件与旧项目的差异，重点关注以下配置项：
  • 更新Microsoft.Data.Tools.Msbuild包版本至与ADS兼容的最新稳定版
  • 确保<TargetFramework>设置为net6.0或更高版本（ADS扩展推荐版本）
  • 统一OutputPath和DacPacOutputPath配置，确保生成的dacpac文件路径可被ADS识别
  • 移除旧项目中针对Visual Studio 2019的特定条件编译或过时属性
• 示例：更新项目文件中的NuGet包引用

  <PackageReference Include="Microsoft.Data.Tools.Msbuild" Version="17.8.0" PrivateAssets="all" />
  

2. 修复大小写引用警告 #

• 批量修正项目中表、列的大小写引用问题，使其符合Azure SQL Database的命名规范（推荐使用 PascalCase）
• 在项目文件中添加以下配置，暂时屏蔽大小写警告以验证发布流程：

  <PropertyGroup>
    <SqlSeverity>16</SqlSeverity>
    <IgnoreSqlCaseWarnings>true</IgnoreSqlCaseWarnings>
  </PropertyGroup>
  

3. 锁定.NET SDK版本 #

• 确认ADS SQL Database Projects扩展要求的.NET SDK版本，安装对应版本
• 在项目根目录创建global.json文件，指定使用的SDK版本，避免多版本冲突：

  {
    "sdk": {
      "version": "6.0.417",
      "rollForward": "latestMinor"
    }
  }
  

4. 手动验证发布流程 #

• 执行dotnet build命令手动构建项目，确认生成了正确的dacpac文件
• 使用SqlPackage.exe手动发布dacpac到Azure SQL Database，验证产物本身的可用性：

  SqlPackage.exe /Action:Publish /SourceFile:"C:\Users\Peter\Source\Repos\Azure DWH\Azure DWH\Database Extract\bin\Output\Database Extract.dacpac" /TargetConnectionString:"Server=tcp:你的服务器名.database.windows.net,1433;Initial Catalog=你的数据库名;Persist Security Info=False;User ID=用户名;Password=密码;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
  

  若手动发布成功，说明问题出在ADS扩展的发布触发逻辑，需进一步排查项目配置与扩展的兼容性。

5. 迁移项目至ADS格式 #

• 使用ADS的「导入项目」功能，选择旧.sqlproj文件，让ADS自动迁移配置至兼容格式
• 对比迁移前后的项目文件差异，保留原有数据库对象的同时，应用ADS的配置规范

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