You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+27-21Lines changed: 27 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -45,7 +45,7 @@ dotnet new sqlproj -s Sql130
45
45
You should now have a project file with the following contents:
46
46
47
47
```xml
48
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
48
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
49
49
<PropertyGroup>
50
50
<TargetFramework>netstandard2.1</TargetFramework>
51
51
<SqlServerVersion>Sql150</SqlServerVersion>
@@ -132,7 +132,7 @@ If you already have a SSDT (.sqlproj) project in your solution, you can keep tha
132
132
There are a lot of properties that can be set on the model in the resulting `.dacpac` file which can be influenced by setting those properties in the project file using the same name. For example, the snippet below sets the `RecoveryMode` property to `Simple`:
@@ -164,7 +164,7 @@ Treating warnings as errors can be optionally enabled by adding a property `Trea
164
164
To suppress specific warnings from being treated as errors, add a comma-separated list of warning codes to `SuppressTSqlWarnings` property in the project file:
@@ -176,7 +176,7 @@ To suppress specific warnings from being treated as errors, add a comma-separate
176
176
You can suppress warnings for a specific file by adding `SuppressTSqlWarnings` for this file:
177
177
178
178
```xml
179
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
179
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
180
180
<PropertyGroup>
181
181
...
182
182
</PropertyGroup>
@@ -197,7 +197,7 @@ You can suppress warnings for a specific file by adding `SuppressTSqlWarnings` f
197
197
To include these scripts into your `.dacpac` add the following to your `.csproj`:
198
198
199
199
```xml
200
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
200
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
201
201
<PropertyGroup>
202
202
...
203
203
</PropertyGroup>
@@ -214,7 +214,7 @@ It is important to note that scripts in the `Pre-Deployment` and `Post-Deploymen
214
214
By default the pre- and/or post-deployment script of referenced packages (both [PackageReference](#package-references) and [ProjectReference](#project-references)) are not run when using `dotnet publish`. This can be optionally enabled by adding a property `RunScriptsFromReferences` to the project file as in the below example:
@@ -231,7 +231,7 @@ By default the pre- and/or post-deployment script of referenced packages (both [
231
231
Especially when using pre- and post-deployment scripts, but also in other scenario's, it might be useful to define variables that can be controlled at deployment time. This is supported using SQLCMD variables. These variables can be defined in your project file using the following syntax:
232
232
233
233
```xml
234
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
234
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
235
235
<PropertyGroup>
236
236
...
237
237
</PropertyGroup>
@@ -256,7 +256,7 @@ Especially when using pre- and post-deployment scripts, but also in other scenar
256
256
`MSBuild.Sdk.SqlProj` supports referencing NuGet packages that contain `.dacpac` packages. These can be referenced by using the `PackageReference` format familiar to .NET developers. They can also be installed through the NuGet Package Manager in Visual Studio.
257
257
258
258
```xml
259
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
259
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
260
260
<PropertyGroup>
261
261
<TargetFramework>netstandard2.1</TargetFramework>
262
262
</PropertyGroup>
@@ -270,7 +270,7 @@ Especially when using pre- and post-deployment scripts, but also in other scenar
270
270
It will assume that the `.dacpac` file is inside the `tools` folder of the referenced package and that it has the same name as the NuGet package. Referenced packages that do not adhere to this convention will be silently ignored. However, you have the ability to override this convention by using the `DacpacName` attribute on the `PackageReference` (introduced in version 2.5.0). For example:
271
271
272
272
```xml
273
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
273
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
274
274
<PropertyGroup>
275
275
<TargetFramework>netstandard2.1</TargetFramework>
276
276
<SqlServerVersion>Sql160</SqlServerVersion>
@@ -287,7 +287,7 @@ This will add a reference to the `tools\SomeOtherDacpac.dacpac` file inside the
287
287
By default, the package reference is treated as being part of the same database. For example, if the reference package contains a `.dacpac` that has a table and a stored procedure and you would `dotnet publish` the project the table and stored procedure from that package will be deployed along with the contents of your project to the same database. If this is not desired, you can add the `DatabaseVariableLiteralValue` item metadata to the `PackageReference` specifying a different database name:
288
288
289
289
```xml
290
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
290
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
291
291
<PropertyGroup>
292
292
<TargetFramework>netstandard2.1</TargetFramework>
293
293
</PropertyGroup>
@@ -304,7 +304,7 @@ You can also use SQLCMD variables to set references, similar to the behavior of
304
304
>Note: Don't forget to define appropriate [SQLCMD variables](#sqlcmd-variables)
305
305
306
306
```xml
307
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
307
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
308
308
<PropertyGroup>
309
309
<TargetFramework>netstandard2.1</TargetFramework>
310
310
</PropertyGroup>
@@ -347,7 +347,7 @@ sqlpackage
347
347
Microsoft has released NuGet packages containing the definitions of the `master` and `msdb` databases. This is useful if you want to reference objects from those databases within your own projects without getting warnings. To reference these, you'll need to use at least version 2.5.0 of MSBuild.Sdk.SqlProj as you'll need to use the `DacpacName` feature for package references described above. For example:
348
348
349
349
```xml
350
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
350
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
351
351
<PropertyGroup>
352
352
<TargetFramework>netstandard2.1</TargetFramework>
353
353
<SqlServerVersion>160</SqlServerVersion>
@@ -368,7 +368,7 @@ For other variants of SQL Server / Azure SQL Database there are dedicated packag
368
368
Similar to package references you can also reference another project by using a `ProjectReference`. These references can be added manually to the project file or they can be added through Visual Studio. For example, consider the following example:
369
369
370
370
```xml
371
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
371
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
372
372
<PropertyGroup>
373
373
<TargetFramework>netstandard2.1</TargetFramework>
374
374
</PropertyGroup>
@@ -382,7 +382,7 @@ Similar to package references you can also reference another project by using a
382
382
This will ensure that `MyOtherProject` is built first and the resulting `.dacpac` will be referenced by this project. This means you can use the objects defined in the other project within the scope of this project. If the other project is representing an entirely different database, you can also use `DatabaseVariableLiteralValue` or SQLCMD variables on the `ProjectReference` similar to `PackageReference`:
383
383
384
384
```xml
385
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
385
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
386
386
<PropertyGroup>
387
387
<TargetFramework>netstandard2.1</TargetFramework>
388
388
</PropertyGroup>
@@ -416,7 +416,7 @@ In order to solve circular references between databases that may have been incor
416
416
`SuppressMissingDependenciesErrors` to both [Package References](#package-references) and [ProjectReferences](#project-references)):
417
417
418
418
```xml
419
-
<ProjectSdk="MSBuild.Sdk.SqlProj/3.0.0">
419
+
<ProjectSdk="MSBuild.Sdk.SqlProj/3.1.0">
420
420
<PropertyGroup>
421
421
<TargetFramework>netstandard2.1</TargetFramework>
422
422
</PropertyGroup>
@@ -438,7 +438,7 @@ In order to solve circular references between databases that may have been incor
438
438
You'll need to set the `PackageProjectUrl` property in the `.csproj` like this:
@@ -513,7 +513,7 @@ To further customize the deployment process, you can use the following propertie
513
513
In addition to these properties, you can also set any of the [documented](https://docs.microsoft.com/dotnet/api/microsoft.sqlserver.dac.dacdeployoptions) deployment options. These are typically set in the project file, for example:
@@ -537,7 +537,7 @@ Most of those properties are simple values (like booleans, strings and integers)
537
537
Instead of using `dotnet publish` to deploy changes to a database, you can also have a full SQL script generated that will create the database from scratch and then run that script against a SQL Server. This can be achieved by adding the following to the project file:
@@ -692,6 +692,12 @@ While the SDK does not help you maintain a [refactor log](https://learn.microsof
692
692
</ItemGroup>
693
693
```
694
694
695
+
## SQL CLR objects support
696
+
697
+
It is not possible to include SQL CLR objects in `MSBuild.Sdk.SqlProj` projects, as they can only be built on .NET Framework.
698
+
699
+
You can work around this by "isolating" your SQL CLR objects in a separate `.sqlproj` project, build and pack the resulting `.dacpac` in a NuGet package on Windows, and then reference this package from your project. Read more about this approach in [this blog post](https://erikej.github.io/dacfx/sqlclr/2025/01/28/dacfx-sqlclr-msbuild-sdk-sqlproj.html).
700
+
695
701
## Known limitations
696
702
697
703
Since this is not an entire project system but only an MSBuild SDK we cannot provide IntelliSense for objects defined within the project. This limitation can be circumvented by connecting the SQL editor to a live database that is used for development purposes.
0 commit comments