Instalar SQL Database Projects en VS Code te toma quince minutos. Lo que tarda meses en construirse es el hábito de tratar tu base de datos como código y este es el primer paso técnico para lograrlo.
Cada vez que un cliente me llama porque «en producción falta una columna que sí estaba en desarrollo», el problema nunca es SQL Server. Es que nadie versionó los cambios. Acá te dejo la guía completa para instalar SQL Database Projects en VS Code desde cero, y por qué a mí me parece el punto de partida obligado para cualquier equipo que quiera dejar de desplegar bases de datos «a mano».
- Vas a poder crear y compilar proyectos
.sqlprojsin instalar Visual Studio completo ni SQL Server en tu máquina. - Necesitás VS Code, el .NET SDK y la extensión
mssql - El paso que más rompe builds (y que casi nadie documenta) es el origen de NuGet: si
nuget.orgno está habilitado, vas a ver el errorMSB4236aunque tengas todo bien instalado. - Al compilar el proyecto se genera un
.dacpac: el artefacto que después vas a versionar en Git y desplegar en cualquier ambiente. - Para publicar ese
.dacpacy ver los cambios reflejados sí necesitás una instancia real de SQL Server o Azure SQL.
¿Por qué versionar tu base de datos como código?
Todo equipo de desarrollo versiona su aplicación. Pull requests, ramas, historial de cambios, revisión de código. Y después llega la base de datos y de golpe volvemos a 2010: scripts sueltos por WhatsApp, un Excel con el «changelog», o directamente memoria de quién tocó qué.
SQL Database Projects es la pieza que rompe esa asimetría. Tu esquema completo , tablas, vistas, procedimientos, índices, funciones todo vive dentro de un proyecto .sqlproj con cada objeto en su propio archivo .sql, trackeado en Git igual que cualquier otra carpeta de tu repositorio.
La ventaja no es solo «orden». Es que un Database Project se compila a un archivo .dacpac, y ese .dacpac es justamente lo que necesitás para automatizar deploys en un pipeline de Azure DevOps o GitHub Actions, o para compararlo contra el estado real de un ambiente con Schema Compare antes de aplicar nada. Sin ese artefacto, no hay CI/CD posible para tu base , solo scripts manuales cruzando los dedos.
Qué necesitás antes de empezar
Para crear y compilar el proyecto no hace falta instalar Visual Studio completo ni SQL Server localmente. Con esto alcanza:
- Visual Studio Code, gratis y multiplataforma.
- El .NET SDK (el SDK completo, no solo el Runtime es un error común y hace fallar el build más adelante).
- La extensión SQL Server (mssql) de Microsoft, que trae incluida la funcionalidad de Database Projects.
- Acceso a nuget.org como origen de paquetes NuGet habilitado.
Para publicar el .dacpac generado y probar los cambios contra una base real, ahí sí vas a necesitar una instancia de SQL Server o Azure SQL pero eso es un paso posterior, no un requisito para empezar.
Paso a paso: instalar SQL Database Projects en VS Code
Paso 1: Instalar Visual Studio Code
Descargá e instalá VS Code desde code.visualstudio.com. Instalación estándar, sin configuración especial.
Paso 2: Instalar el .NET SDK
Descargá el SDK desde dotnet.microsoft.com/download. Remarco esto porque es el primer punto donde la gente se equivoca: instalá el SDK, no solamente el Runtime. El Runtime alcanza para ejecutar aplicaciones .NET ya compiladas, pero Database Projects necesita el SDK para poder compilar.
Después de instalar, abrí una terminal nueva y verificá:
dotnet --list-sdksSi no ves ningún SDK listado, la instalación no terminó bien o estás en una terminal vieja que no recargó el PATH.
Paso 3: Instalar la extensión SQL Server (mssql)
En VS Code:
- Abrí Extensiones con
Ctrl+Shift+X. - Buscá SQL Server (mssql), publicada por Microsoft.
- Hacé clic en Install.
Paso 4: verificar NuGet (el paso que nadie documenta)
Esta es la parte que más dolores de cabeza evita. En una terminal de VS Code, ejecutá:
dotnet nuget list sourceComprobá que nuget.org figure como origen habilitado. Si no aparece, agregalo:
dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.orgSi aparece pero deshabilitado, habilitalo:
dotnet nuget enable source nuget.orgEste paso es clave: si nuget.org no está disponible, el build puede fallar con MSB4236: The SDK 'Microsoft.Build.Sql/...' specified could not be found, aunque el .NET SDK esté perfectamente instalado. Me ha pasado con clientes que tienen políticas corporativas de proxy o feeds internos de NuGet que pisan el origen público sin que nadie lo note y ahí aparece este error que parece de instalación pero es de configuración.
Paso 5: crear y compilar tu primer proyecto
- Reiniciá VS Code.
- Abrí una carpeta de trabajo.
- Entrá en la vista Database Projects.
- Seleccioná New Project.
- Elegí la plataforma de destino y un nombre.
- Cuando se solicite, seleccioná SDK-style: Yes.
- Hacé clic derecho sobre el proyecto y seleccioná Build.
Si la compilación termina correctamente, se genera un archivo .dacpac en bin\Debug. Ese archivo es tu esquema completo empaquetado y listo para desplegar.
Errores comunes al instalar SQL Database Projects
Error MSB4236: The SDK 'Microsoft.Build.Sql/...' specified could not be found
Casi siempre es NuGet, no el .NET SDK. Volvé al Paso 4 y confirmá que nuget.org esté habilitado como origen.
El proyecto no ofrece la opción «SDK-style»
Reiniciá VS Code después de instalar la extensión y el SDK. Si persiste, corré dotnet --list-sdks para confirmar que el SDK quedó realmente instalado y visible en el PATH.
dotnet build no encuentra el archivo .sqlproj
Verificá que estás parado en la carpeta correcta con la terminal, o pasá la ruta completa al archivo.
De un .dacpac suelto a un pipeline real de DevOps
Compilar un .dacpac en tu máquina es el punto de partida, no el objetivo final. El salto real pasa cuando ese mismo proceso corre en un pipeline: cada Pull Request compila el proyecto, valida que el esquema no tenga errores, y en un merge a la rama principal el .dacpac se publica automáticamente contra el ambiente correspondiente dev, QA, producción con SqlPackage o la tarea de deploy de Azure DevOps / GitHub Actions.
Lo interesante es que no hace falta migrar todo tu equipo a Visual Studio ni forzar a nadie a dejar el SSMS. Como
Con los clientes que implementamos este esquema, el momento de mayor estrés del sprint el deploy de base de datos pasó a ser un paso más del pipeline y no un evento.
Preguntas frecuentes
¿Necesito instalar Visual Studio completo para usar SQL Database Projects?
No. Para crear y compilar un proyecto .sqlproj alcanza con Visual Studio Code, el .NET SDK y la extensión mssql. Visual Studio completo es una alternativa, no un requisito.
¿Puedo usar SQL Database Projects sin tener SQL Server instalado?
Sí, para crear y compilar el proyecto no necesitás ninguna instancia de SQL Server. Solo la necesitás cuando quieras publicar el .dacpac generado y ver los cambios aplicados en una base real (local, en un servidor o en Azure SQL).
¿Qué es el error MSB4236 y por qué aparece si tengo todo instalado?
Es el error que tira dotnet build cuando no encuentra el SDK Microsoft.Build.Sql, y casi siempre se debe a que el origen nuget.org está deshabilitado o ausente en la configuración de NuGet de tu máquina no a un problema con el .NET SDK en sí.
¿Cuál es la diferencia entre compilar y publicar un dacpac?
Compilar valida el esquema y genera el archivo .dacpac localmente, sin tocar ninguna base de datos. Publicar es el paso siguiente: aplica ese .dacpac contra una instancia real de SQL Server o Azure SQL, generando (o ejecutando) el script de cambios necesario.
¿Necesitás ayuda armando tu pipeline de DevOps para SQL Server?
En TriggerDB Consulting ayudamos a equipos a pasar de scripts sueltos a un flujo real de control de versiones, compilación y despliegue automatizado para sus bases de datos SQL Server y Azure SQL.
👉 Hablemos contame tu situación y vemos cómo armar ese pipeline sin parar tu operación.
