SSDT 是什么，它和 C# 项目怎么关联
SSDT（SQL Server Data Tools）不是 C# 运行时组件，也不是 NuGet 包，而是一套 Visual Studio 内置的数据库开发工具集。它不编译进你的
C# .NET程序，但能让你把数据库模式（表、视图、存储过程等）作为“代码”纳入 C# 解决方案统一管理。关键在于：数据库逻辑变成
.sqlproj项目，和
.csproj并列存在于同一解决方案中，共享源码控制、构建流程和 CI/CD 管道。 SSDT 项目默认使用 T-SQL 编写对象定义，不依赖运行时连接，所有校验在设计时完成 它通过
CREATE/
ALTER脚本生成机制，在部署时自动计算差异（diff），生成增量升级脚本 C# 项目可通过
SqlConnection正常访问 SSDT 部署后的数据库，两者解耦；但若 C# 代码强依赖某张表或函数，建议在 SSDT 项目中用
Refactor > Rename同步修改，避免手动遗漏
如何在现有 C# 解决方案中添加 SSDT 项目
打开已有
.sln文件后，右键解决方案 → “添加” → “新建项目”，搜索 “SQL Server Database Project”。注意选择匹配目标 SQL Server 版本的模板（如 SQL Server 2019、Azure SQL），版本错配会导致发布失败或功能不可用（例如
STRING_AGG在 2016 下不可用）。 若项目已含数据库脚本（如
init.sql），不要直接复制粘贴到 SSDT；应右键项目 → “导入” → “数据库”，连上实际库后反向工程为 SSDT 结构 导入后检查
dbo架构是否被正确识别；若出现
unresolved reference错误，大概率是未声明引用（如系统视图、外部数据库对象），需右键项目 → “属性” → “数据库参考” 添加对应数据库引用或“系统数据库引用” SSDT 默认启用“始终重新创建数据库”模式（
DropObjectsNotInSource = true），上线前务必关闭该选项，否则会清空生产数据
部署时常见失败原因和绕过方式
SSDT 发布失败通常不报 C# 异常，而是卡在
SqlPackage.exe执行阶段，错误信息出现在输出窗口或
.publish.xml日志中。最常遇到的三类问题：
Unable to connect to master or target server：SQL Server 实例名或登录凭据不对，检查
.publish.xml中
TargetConnectionString是否含
Integrated Security=true（域环境可用）或明确指定
User ID/
Password
Script block contains statements that cannot be executed in this context：比如在部署脚本中写了
SELECT TOP 10 <em></em>或
/ --POSTDEPLOYMENT */区块中，并设为“作为脚本包含”
Column 'xxx' in table 'yyy' is invalid for creating a default constraint：字段类型与默认值不兼容（如
nvarchar(50)对应
GETDATE()），这类错误在 SSDT 设计时不会报，只在生成部署脚本时暴露，需人工核对
DEFAULT约束定义
如何让 C# 应用感知数据库版本并做兼容处理
SSDT 本身不提供运行时版本号 API，但你可以用以下两种轻量方式实现“数据库就绪检查”：
在 SSDT 项目中建一张SchemaVersion表，每次发布前手动或用 Pre-Deployment 脚本更新版本号（如
INSERT INTO SchemaVersion VALUES ('2024.05.01')），C# 启动时查该表并与程序预期版本比对
利用 SSDT 的 Build Events（项目属性 → “生成事件”），在构建后自动将当前
$(ConfigurationName)和
$(ProjectVersion)写入一个
db.version.json文件，再由 C# 读取该文件决定是否跳过某些初始化逻辑
SSDT 的真正复杂点不在语法或部署命令，而在于它强制你把“数据库变更”当作有顺序、可回滚、可验证的代码变更来对待——哪怕只是加个字段，也得想清楚它在旧数据上怎么生效、C# 层要不要加空值判断、下游报表是否受影响。这些事，
SqlPackage.exe不会替你决定。
