Month: February 2024
Updates from 162.1 and 162.2 releases of SqlPackage and the DacFx ecosystem
Within the past 4 months, we’ve had 2 minor releases and a patch release for SqlPackage. In this article, we’ll recap the features and notable changes from SqlPackage 162.1 (October 2023) and 162.2 (February 2024). Several new features focus on giving you more control over the performance of deployments by preventing potential costly operations and opting in to online operations. We’ve also introduced an alternative option for data portability that can provide significant speed improvements to databases in Azure. Read on for information about these improvements and more, all from the recent releases in the DacFx ecosystem. Information on features and fixes is available in the itemized release notes for SqlPackage.
.NET 8 support
The 162.2 release of DacFx and SqlPackage introduces support for .NET 8. SqlPackage installation as a dotnet tool is available with the .NET 6 and .NET 8 SDK. Install or update easily with a single command if the .NET SDK is installed:
# install
dotnet tool install -g microsoft.sqlpackage
# update
dotnet tool update -g microsoft.sqlpackage
Online index operations
Starting with SqlPackage 162.2, online index operations are supported during publish on applicable environments (including Azure SQL Database, Azure SQL Managed Instance, and SQL Server Enterprise edition). Online index operations can reduce the application performance impact of a deployment by supporting concurrent access to the underlying data. For more guidance on online index operations and to determine if your environment supports them, check out the SQL documentation on guidelines for online index operations.
Directing index operations to be performed online across a deployment can be achieved with a command line property new to SqlPackage 162.2, “PerformIndexOperationsOnline”. The property defaults to false, where just as in previous versions of SqlPackage, index operations are performed with the index temporarily offline. If set to true, the index operations in the deployment will be performed online. When the option is requested on a database where online index operations don’t apply, SqlPackage will emit a warning and continue the deployment.
An example of this property in use to deploy index changes online is:
sqlpackage /Action:Publish /SourceFile:yourdatabase.dacpac /TargetConnectionString:”yourconnectionstring” /p:PerformIndexOperationsOnline=True
More granular control over the index operations can be achieved by including the ONLINE=ON/OFF keyword in index definitions in your SQL project. The online property will be included in the database model (.dacpac file) from the SQL project build. Deployment of that object with SqlPackage 162.2 and above will follow the keyword used in the definition, superseding any options supplied to the publish command. This applies to both ONLINE=ON and ONLINE=OFF settings.
DacFx 162.2 is required for SQL project inclusion of ONLINE keywords with indexes and is included with the Microsoft.Build.Sql SQL projects SDK version 0.1.15-preview. For use with non-SDK SQL projects, DacFx 162.2 will be included in future releases of SQL projects in Azure Data Studio, VS Code, and Visual Studio. The updated SDK or SQL projects extension is required to incorporate the index property into the dacpac file. Only SqlPackage 162.2 is required to leverage the publish property “PerformIndexOperationsOnline”.
Block table recreation
With SqlPackage publish operations, you can apply a new desired schema state to an existing database. You define what object definitions you want in the database and pass a dacpac file to SqlPackage, which in turn calculates the operations necessary to update the target database to match those objects. The set of operations are known as a “deployment plan”.
A deployment plan will not destroy user data in the database in the process of altering objects, but it can have computationally intensive steps or unintended consequences when features like change tracking are in use. In SqlPackage 162.1.167, we’ve introduced an optional property, /p:AllowTableRecreation, which allows you to stop any deployments from being carried out that have a table recreation step in the deployment plan.
/p:AllowTableRecreation=true (default) SqlPackage will recreate tables when necessary and use data migration steps to preserve your user data
/p:AllowTableRecreation=false SqlPackage will check the deployment plan for table recreation steps and stop before starting the plan if a table recreation step is included
SqlPackage + Parquet files (preview)
Database portability, the ability to take a SQL database from a server and move it to a different server even across SQL Server and Azure SQL hosting options, is most often achieved through import and export of bacpac files. Reading and writing the singular bacpac files can be difficult when databases are over 100 GB and network latency can be a significant concern. SqlPackage 162.1 introduced the option to move the data in your database with parquet files in Azure Blob Storage, reducing the operation overhead on the network and local storage components of your architecture.
Data movement in parquet files is available through the extract and publish actions in SqlPackage. With extract, the database schema (.dacpac file) is written to the local client running SqlPackage and the data is written to Azure Blob Storage in Parquet format. With publish, the database schema (.dacpac file) is read from the local client running SqlPackage and the data is read from or written to Azure Blob Storage in Parquet format.
The parquet data file feature benefits larger databases hosted in Azure with significantly faster data transfer speeds due to the architecture shift of the data export to cloud storage and better parallelization in the SQL engine. This functionality is in preview for SQL Server 2022 and Azure SQL Managed Instance and can be expected to enter preview for Azure SQL Database in the future. Dive into trying out data portability with dacpacs and parquet files from the SqlPackage documentation on parquet files.
Microsoft.Build.Sql
The Microsoft.Build.Sql library for SDK-style projects continues in the preview development phase and version 0.1.15-preview was just released. Code analysis rules have been enabled for execution during build time with .NET 6 and .NET 8, opening the door to performing quality and performance reviews of your database code on the SQL project. To enable code analysis rules on your project, add the item seen on line 7 of the following sample to your project definition (<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>).
<Project DefaultTargets=”Build”>
<Sdk Name=”Microsoft.Build.Sql” Version=”0.1.15-preview” />
<PropertyGroup>
<Name>synapseexport</Name>
<DSP>Microsoft.Data.Tools.Schema.Sql.Sql160DatabaseSchemaProvider</DSP>
<ModelCollation>1033, CI</ModelCollation>
<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
</PropertyGroup>
</Project>
During build time, the objects in the project will be checked against a default set of code analysis rules. Code analysis rules can be customized through DacFx extensibility.
Ways to get involved
In early 2024, we added preview releases of SqlPackage to the dotnet tool feed, such that not only do you have early access to DacFx changes but you can directly test SqlPackage as well. Get the quick instructions on installing and updating the preview releases in the SqlPackage documentation.
Most of the issues fixed in this release were reported through our GitHub community, and in several cases the person reporting put together great bug reports with reproducing scripts. Feature requests are also discussed within the GitHub community in some cases, including the online index operations and blocking table recreation capabilities. All are welcome to stop by the GitHub repository to provide feedback, whether it is bug reports, questions, or enhancement suggestions.
Microsoft Tech Community – Latest Blogs –Read More
Updates from 162.1 and 162.2 releases of SqlPackage and the DacFx ecosystem
Within the past 4 months, we’ve had 2 minor releases and a patch release for SqlPackage. In this article, we’ll recap the features and notable changes from SqlPackage 162.1 (October 2023) and 162.2 (February 2024). Several new features focus on giving you more control over the performance of deployments by preventing potential costly operations and opting in to online operations. We’ve also introduced an alternative option for data portability that can provide significant speed improvements to databases in Azure. Read on for information about these improvements and more, all from the recent releases in the DacFx ecosystem. Information on features and fixes is available in the itemized release notes for SqlPackage.
.NET 8 support
The 162.2 release of DacFx and SqlPackage introduces support for .NET 8. SqlPackage installation as a dotnet tool is available with the .NET 6 and .NET 8 SDK. Install or update easily with a single command if the .NET SDK is installed:
# install
dotnet tool install -g microsoft.sqlpackage
# update
dotnet tool update -g microsoft.sqlpackage
Online index operations
Starting with SqlPackage 162.2, online index operations are supported during publish on applicable environments (including Azure SQL Database, Azure SQL Managed Instance, and SQL Server Enterprise edition). Online index operations can reduce the application performance impact of a deployment by supporting concurrent access to the underlying data. For more guidance on online index operations and to determine if your environment supports them, check out the SQL documentation on guidelines for online index operations.
Directing index operations to be performed online across a deployment can be achieved with a command line property new to SqlPackage 162.2, “PerformIndexOperationsOnline”. The property defaults to false, where just as in previous versions of SqlPackage, index operations are performed with the index temporarily offline. If set to true, the index operations in the deployment will be performed online. When the option is requested on a database where online index operations don’t apply, SqlPackage will emit a warning and continue the deployment.
An example of this property in use to deploy index changes online is:
sqlpackage /Action:Publish /SourceFile:yourdatabase.dacpac /TargetConnectionString:”yourconnectionstring” /p:PerformIndexOperationsOnline=True
More granular control over the index operations can be achieved by including the ONLINE=ON/OFF keyword in index definitions in your SQL project. The online property will be included in the database model (.dacpac file) from the SQL project build. Deployment of that object with SqlPackage 162.2 and above will follow the keyword used in the definition, superseding any options supplied to the publish command. This applies to both ONLINE=ON and ONLINE=OFF settings.
DacFx 162.2 is required for SQL project inclusion of ONLINE keywords with indexes and is included with the Microsoft.Build.Sql SQL projects SDK version 0.1.15-preview. For use with non-SDK SQL projects, DacFx 162.2 will be included in future releases of SQL projects in Azure Data Studio, VS Code, and Visual Studio. The updated SDK or SQL projects extension is required to incorporate the index property into the dacpac file. Only SqlPackage 162.2 is required to leverage the publish property “PerformIndexOperationsOnline”.
Block table recreation
With SqlPackage publish operations, you can apply a new desired schema state to an existing database. You define what object definitions you want in the database and pass a dacpac file to SqlPackage, which in turn calculates the operations necessary to update the target database to match those objects. The set of operations are known as a “deployment plan”.
A deployment plan will not destroy user data in the database in the process of altering objects, but it can have computationally intensive steps or unintended consequences when features like change tracking are in use. In SqlPackage 162.1.167, we’ve introduced an optional property, /p:AllowTableRecreation, which allows you to stop any deployments from being carried out that have a table recreation step in the deployment plan.
/p:AllowTableRecreation=true (default) SqlPackage will recreate tables when necessary and use data migration steps to preserve your user data
/p:AllowTableRecreation=false SqlPackage will check the deployment plan for table recreation steps and stop before starting the plan if a table recreation step is included
SqlPackage + Parquet files (preview)
Database portability, the ability to take a SQL database from a server and move it to a different server even across SQL Server and Azure SQL hosting options, is most often achieved through import and export of bacpac files. Reading and writing the singular bacpac files can be difficult when databases are over 100 GB and network latency can be a significant concern. SqlPackage 162.1 introduced the option to move the data in your database with parquet files in Azure Blob Storage, reducing the operation overhead on the network and local storage components of your architecture.
Data movement in parquet files is available through the extract and publish actions in SqlPackage. With extract, the database schema (.dacpac file) is written to the local client running SqlPackage and the data is written to Azure Blob Storage in Parquet format. With publish, the database schema (.dacpac file) is read from the local client running SqlPackage and the data is read from or written to Azure Blob Storage in Parquet format.
The parquet data file feature benefits larger databases hosted in Azure with significantly faster data transfer speeds due to the architecture shift of the data export to cloud storage and better parallelization in the SQL engine. This functionality is in preview for SQL Server 2022 and Azure SQL Managed Instance and can be expected to enter preview for Azure SQL Database in the future. Dive into trying out data portability with dacpacs and parquet files from the SqlPackage documentation on parquet files.
Microsoft.Build.Sql
The Microsoft.Build.Sql library for SDK-style projects continues in the preview development phase and version 0.1.15-preview was just released. Code analysis rules have been enabled for execution during build time with .NET 6 and .NET 8, opening the door to performing quality and performance reviews of your database code on the SQL project. To enable code analysis rules on your project, add the item seen on line 7 of the following sample to your project definition (<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>).
<Project DefaultTargets=”Build”>
<Sdk Name=”Microsoft.Build.Sql” Version=”0.1.15-preview” />
<PropertyGroup>
<Name>synapseexport</Name>
<DSP>Microsoft.Data.Tools.Schema.Sql.Sql160DatabaseSchemaProvider</DSP>
<ModelCollation>1033, CI</ModelCollation>
<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
</PropertyGroup>
</Project>
During build time, the objects in the project will be checked against a default set of code analysis rules. Code analysis rules can be customized through DacFx extensibility.
Ways to get involved
In early 2024, we added preview releases of SqlPackage to the dotnet tool feed, such that not only do you have early access to DacFx changes but you can directly test SqlPackage as well. Get the quick instructions on installing and updating the preview releases in the SqlPackage documentation.
Most of the issues fixed in this release were reported through our GitHub community, and in several cases the person reporting put together great bug reports with reproducing scripts. Feature requests are also discussed within the GitHub community in some cases, including the online index operations and blocking table recreation capabilities. All are welcome to stop by the GitHub repository to provide feedback, whether it is bug reports, questions, or enhancement suggestions.
Microsoft Tech Community – Latest Blogs –Read More
Updates from 162.1 and 162.2 releases of SqlPackage and the DacFx ecosystem
Within the past 4 months, we’ve had 2 minor releases and a patch release for SqlPackage. In this article, we’ll recap the features and notable changes from SqlPackage 162.1 (October 2023) and 162.2 (February 2024). Several new features focus on giving you more control over the performance of deployments by preventing potential costly operations and opting in to online operations. We’ve also introduced an alternative option for data portability that can provide significant speed improvements to databases in Azure. Read on for information about these improvements and more, all from the recent releases in the DacFx ecosystem. Information on features and fixes is available in the itemized release notes for SqlPackage.
.NET 8 support
The 162.2 release of DacFx and SqlPackage introduces support for .NET 8. SqlPackage installation as a dotnet tool is available with the .NET 6 and .NET 8 SDK. Install or update easily with a single command if the .NET SDK is installed:
# install
dotnet tool install -g microsoft.sqlpackage
# update
dotnet tool update -g microsoft.sqlpackage
Online index operations
Starting with SqlPackage 162.2, online index operations are supported during publish on applicable environments (including Azure SQL Database, Azure SQL Managed Instance, and SQL Server Enterprise edition). Online index operations can reduce the application performance impact of a deployment by supporting concurrent access to the underlying data. For more guidance on online index operations and to determine if your environment supports them, check out the SQL documentation on guidelines for online index operations.
Directing index operations to be performed online across a deployment can be achieved with a command line property new to SqlPackage 162.2, “PerformIndexOperationsOnline”. The property defaults to false, where just as in previous versions of SqlPackage, index operations are performed with the index temporarily offline. If set to true, the index operations in the deployment will be performed online. When the option is requested on a database where online index operations don’t apply, SqlPackage will emit a warning and continue the deployment.
An example of this property in use to deploy index changes online is:
sqlpackage /Action:Publish /SourceFile:yourdatabase.dacpac /TargetConnectionString:”yourconnectionstring” /p:PerformIndexOperationsOnline=True
More granular control over the index operations can be achieved by including the ONLINE=ON/OFF keyword in index definitions in your SQL project. The online property will be included in the database model (.dacpac file) from the SQL project build. Deployment of that object with SqlPackage 162.2 and above will follow the keyword used in the definition, superseding any options supplied to the publish command. This applies to both ONLINE=ON and ONLINE=OFF settings.
DacFx 162.2 is required for SQL project inclusion of ONLINE keywords with indexes and is included with the Microsoft.Build.Sql SQL projects SDK version 0.1.15-preview. For use with non-SDK SQL projects, DacFx 162.2 will be included in future releases of SQL projects in Azure Data Studio, VS Code, and Visual Studio. The updated SDK or SQL projects extension is required to incorporate the index property into the dacpac file. Only SqlPackage 162.2 is required to leverage the publish property “PerformIndexOperationsOnline”.
Block table recreation
With SqlPackage publish operations, you can apply a new desired schema state to an existing database. You define what object definitions you want in the database and pass a dacpac file to SqlPackage, which in turn calculates the operations necessary to update the target database to match those objects. The set of operations are known as a “deployment plan”.
A deployment plan will not destroy user data in the database in the process of altering objects, but it can have computationally intensive steps or unintended consequences when features like change tracking are in use. In SqlPackage 162.1.167, we’ve introduced an optional property, /p:AllowTableRecreation, which allows you to stop any deployments from being carried out that have a table recreation step in the deployment plan.
/p:AllowTableRecreation=true (default) SqlPackage will recreate tables when necessary and use data migration steps to preserve your user data
/p:AllowTableRecreation=false SqlPackage will check the deployment plan for table recreation steps and stop before starting the plan if a table recreation step is included
SqlPackage + Parquet files (preview)
Database portability, the ability to take a SQL database from a server and move it to a different server even across SQL Server and Azure SQL hosting options, is most often achieved through import and export of bacpac files. Reading and writing the singular bacpac files can be difficult when databases are over 100 GB and network latency can be a significant concern. SqlPackage 162.1 introduced the option to move the data in your database with parquet files in Azure Blob Storage, reducing the operation overhead on the network and local storage components of your architecture.
Data movement in parquet files is available through the extract and publish actions in SqlPackage. With extract, the database schema (.dacpac file) is written to the local client running SqlPackage and the data is written to Azure Blob Storage in Parquet format. With publish, the database schema (.dacpac file) is read from the local client running SqlPackage and the data is read from or written to Azure Blob Storage in Parquet format.
The parquet data file feature benefits larger databases hosted in Azure with significantly faster data transfer speeds due to the architecture shift of the data export to cloud storage and better parallelization in the SQL engine. This functionality is in preview for SQL Server 2022 and Azure SQL Managed Instance and can be expected to enter preview for Azure SQL Database in the future. Dive into trying out data portability with dacpacs and parquet files from the SqlPackage documentation on parquet files.
Microsoft.Build.Sql
The Microsoft.Build.Sql library for SDK-style projects continues in the preview development phase and version 0.1.15-preview was just released. Code analysis rules have been enabled for execution during build time with .NET 6 and .NET 8, opening the door to performing quality and performance reviews of your database code on the SQL project. To enable code analysis rules on your project, add the item seen on line 7 of the following sample to your project definition (<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>).
<Project DefaultTargets=”Build”>
<Sdk Name=”Microsoft.Build.Sql” Version=”0.1.15-preview” />
<PropertyGroup>
<Name>synapseexport</Name>
<DSP>Microsoft.Data.Tools.Schema.Sql.Sql160DatabaseSchemaProvider</DSP>
<ModelCollation>1033, CI</ModelCollation>
<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
</PropertyGroup>
</Project>
During build time, the objects in the project will be checked against a default set of code analysis rules. Code analysis rules can be customized through DacFx extensibility.
Ways to get involved
In early 2024, we added preview releases of SqlPackage to the dotnet tool feed, such that not only do you have early access to DacFx changes but you can directly test SqlPackage as well. Get the quick instructions on installing and updating the preview releases in the SqlPackage documentation.
Most of the issues fixed in this release were reported through our GitHub community, and in several cases the person reporting put together great bug reports with reproducing scripts. Feature requests are also discussed within the GitHub community in some cases, including the online index operations and blocking table recreation capabilities. All are welcome to stop by the GitHub repository to provide feedback, whether it is bug reports, questions, or enhancement suggestions.
Microsoft Tech Community – Latest Blogs –Read More
Updates from 162.1 and 162.2 releases of SqlPackage and the DacFx ecosystem
Within the past 4 months, we’ve had 2 minor releases and a patch release for SqlPackage. In this article, we’ll recap the features and notable changes from SqlPackage 162.1 (October 2023) and 162.2 (February 2024). Several new features focus on giving you more control over the performance of deployments by preventing potential costly operations and opting in to online operations. We’ve also introduced an alternative option for data portability that can provide significant speed improvements to databases in Azure. Read on for information about these improvements and more, all from the recent releases in the DacFx ecosystem. Information on features and fixes is available in the itemized release notes for SqlPackage.
.NET 8 support
The 162.2 release of DacFx and SqlPackage introduces support for .NET 8. SqlPackage installation as a dotnet tool is available with the .NET 6 and .NET 8 SDK. Install or update easily with a single command if the .NET SDK is installed:
# install
dotnet tool install -g microsoft.sqlpackage
# update
dotnet tool update -g microsoft.sqlpackage
Online index operations
Starting with SqlPackage 162.2, online index operations are supported during publish on applicable environments (including Azure SQL Database, Azure SQL Managed Instance, and SQL Server Enterprise edition). Online index operations can reduce the application performance impact of a deployment by supporting concurrent access to the underlying data. For more guidance on online index operations and to determine if your environment supports them, check out the SQL documentation on guidelines for online index operations.
Directing index operations to be performed online across a deployment can be achieved with a command line property new to SqlPackage 162.2, “PerformIndexOperationsOnline”. The property defaults to false, where just as in previous versions of SqlPackage, index operations are performed with the index temporarily offline. If set to true, the index operations in the deployment will be performed online. When the option is requested on a database where online index operations don’t apply, SqlPackage will emit a warning and continue the deployment.
An example of this property in use to deploy index changes online is:
sqlpackage /Action:Publish /SourceFile:yourdatabase.dacpac /TargetConnectionString:”yourconnectionstring” /p:PerformIndexOperationsOnline=True
More granular control over the index operations can be achieved by including the ONLINE=ON/OFF keyword in index definitions in your SQL project. The online property will be included in the database model (.dacpac file) from the SQL project build. Deployment of that object with SqlPackage 162.2 and above will follow the keyword used in the definition, superseding any options supplied to the publish command. This applies to both ONLINE=ON and ONLINE=OFF settings.
DacFx 162.2 is required for SQL project inclusion of ONLINE keywords with indexes and is included with the Microsoft.Build.Sql SQL projects SDK version 0.1.15-preview. For use with non-SDK SQL projects, DacFx 162.2 will be included in future releases of SQL projects in Azure Data Studio, VS Code, and Visual Studio. The updated SDK or SQL projects extension is required to incorporate the index property into the dacpac file. Only SqlPackage 162.2 is required to leverage the publish property “PerformIndexOperationsOnline”.
Block table recreation
With SqlPackage publish operations, you can apply a new desired schema state to an existing database. You define what object definitions you want in the database and pass a dacpac file to SqlPackage, which in turn calculates the operations necessary to update the target database to match those objects. The set of operations are known as a “deployment plan”.
A deployment plan will not destroy user data in the database in the process of altering objects, but it can have computationally intensive steps or unintended consequences when features like change tracking are in use. In SqlPackage 162.1.167, we’ve introduced an optional property, /p:AllowTableRecreation, which allows you to stop any deployments from being carried out that have a table recreation step in the deployment plan.
/p:AllowTableRecreation=true (default) SqlPackage will recreate tables when necessary and use data migration steps to preserve your user data
/p:AllowTableRecreation=false SqlPackage will check the deployment plan for table recreation steps and stop before starting the plan if a table recreation step is included
SqlPackage + Parquet files (preview)
Database portability, the ability to take a SQL database from a server and move it to a different server even across SQL Server and Azure SQL hosting options, is most often achieved through import and export of bacpac files. Reading and writing the singular bacpac files can be difficult when databases are over 100 GB and network latency can be a significant concern. SqlPackage 162.1 introduced the option to move the data in your database with parquet files in Azure Blob Storage, reducing the operation overhead on the network and local storage components of your architecture.
Data movement in parquet files is available through the extract and publish actions in SqlPackage. With extract, the database schema (.dacpac file) is written to the local client running SqlPackage and the data is written to Azure Blob Storage in Parquet format. With publish, the database schema (.dacpac file) is read from the local client running SqlPackage and the data is read from or written to Azure Blob Storage in Parquet format.
The parquet data file feature benefits larger databases hosted in Azure with significantly faster data transfer speeds due to the architecture shift of the data export to cloud storage and better parallelization in the SQL engine. This functionality is in preview for SQL Server 2022 and Azure SQL Managed Instance and can be expected to enter preview for Azure SQL Database in the future. Dive into trying out data portability with dacpacs and parquet files from the SqlPackage documentation on parquet files.
Microsoft.Build.Sql
The Microsoft.Build.Sql library for SDK-style projects continues in the preview development phase and version 0.1.15-preview was just released. Code analysis rules have been enabled for execution during build time with .NET 6 and .NET 8, opening the door to performing quality and performance reviews of your database code on the SQL project. To enable code analysis rules on your project, add the item seen on line 7 of the following sample to your project definition (<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>).
<Project DefaultTargets=”Build”>
<Sdk Name=”Microsoft.Build.Sql” Version=”0.1.15-preview” />
<PropertyGroup>
<Name>synapseexport</Name>
<DSP>Microsoft.Data.Tools.Schema.Sql.Sql160DatabaseSchemaProvider</DSP>
<ModelCollation>1033, CI</ModelCollation>
<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
</PropertyGroup>
</Project>
During build time, the objects in the project will be checked against a default set of code analysis rules. Code analysis rules can be customized through DacFx extensibility.
Ways to get involved
In early 2024, we added preview releases of SqlPackage to the dotnet tool feed, such that not only do you have early access to DacFx changes but you can directly test SqlPackage as well. Get the quick instructions on installing and updating the preview releases in the SqlPackage documentation.
Most of the issues fixed in this release were reported through our GitHub community, and in several cases the person reporting put together great bug reports with reproducing scripts. Feature requests are also discussed within the GitHub community in some cases, including the online index operations and blocking table recreation capabilities. All are welcome to stop by the GitHub repository to provide feedback, whether it is bug reports, questions, or enhancement suggestions.
Microsoft Tech Community – Latest Blogs –Read More
Updates from 162.1 and 162.2 releases of SqlPackage and the DacFx ecosystem
Within the past 4 months, we’ve had 2 minor releases and a patch release for SqlPackage. In this article, we’ll recap the features and notable changes from SqlPackage 162.1 (October 2023) and 162.2 (February 2024). Several new features focus on giving you more control over the performance of deployments by preventing potential costly operations and opting in to online operations. We’ve also introduced an alternative option for data portability that can provide significant speed improvements to databases in Azure. Read on for information about these improvements and more, all from the recent releases in the DacFx ecosystem. Information on features and fixes is available in the itemized release notes for SqlPackage.
.NET 8 support
The 162.2 release of DacFx and SqlPackage introduces support for .NET 8. SqlPackage installation as a dotnet tool is available with the .NET 6 and .NET 8 SDK. Install or update easily with a single command if the .NET SDK is installed:
# install
dotnet tool install -g microsoft.sqlpackage
# update
dotnet tool update -g microsoft.sqlpackage
Online index operations
Starting with SqlPackage 162.2, online index operations are supported during publish on applicable environments (including Azure SQL Database, Azure SQL Managed Instance, and SQL Server Enterprise edition). Online index operations can reduce the application performance impact of a deployment by supporting concurrent access to the underlying data. For more guidance on online index operations and to determine if your environment supports them, check out the SQL documentation on guidelines for online index operations.
Directing index operations to be performed online across a deployment can be achieved with a command line property new to SqlPackage 162.2, “PerformIndexOperationsOnline”. The property defaults to false, where just as in previous versions of SqlPackage, index operations are performed with the index temporarily offline. If set to true, the index operations in the deployment will be performed online. When the option is requested on a database where online index operations don’t apply, SqlPackage will emit a warning and continue the deployment.
An example of this property in use to deploy index changes online is:
sqlpackage /Action:Publish /SourceFile:yourdatabase.dacpac /TargetConnectionString:”yourconnectionstring” /p:PerformIndexOperationsOnline=True
More granular control over the index operations can be achieved by including the ONLINE=ON/OFF keyword in index definitions in your SQL project. The online property will be included in the database model (.dacpac file) from the SQL project build. Deployment of that object with SqlPackage 162.2 and above will follow the keyword used in the definition, superseding any options supplied to the publish command. This applies to both ONLINE=ON and ONLINE=OFF settings.
DacFx 162.2 is required for SQL project inclusion of ONLINE keywords with indexes and is included with the Microsoft.Build.Sql SQL projects SDK version 0.1.15-preview. For use with non-SDK SQL projects, DacFx 162.2 will be included in future releases of SQL projects in Azure Data Studio, VS Code, and Visual Studio. The updated SDK or SQL projects extension is required to incorporate the index property into the dacpac file. Only SqlPackage 162.2 is required to leverage the publish property “PerformIndexOperationsOnline”.
Block table recreation
With SqlPackage publish operations, you can apply a new desired schema state to an existing database. You define what object definitions you want in the database and pass a dacpac file to SqlPackage, which in turn calculates the operations necessary to update the target database to match those objects. The set of operations are known as a “deployment plan”.
A deployment plan will not destroy user data in the database in the process of altering objects, but it can have computationally intensive steps or unintended consequences when features like change tracking are in use. In SqlPackage 162.1.167, we’ve introduced an optional property, /p:AllowTableRecreation, which allows you to stop any deployments from being carried out that have a table recreation step in the deployment plan.
/p:AllowTableRecreation=true (default) SqlPackage will recreate tables when necessary and use data migration steps to preserve your user data
/p:AllowTableRecreation=false SqlPackage will check the deployment plan for table recreation steps and stop before starting the plan if a table recreation step is included
SqlPackage + Parquet files (preview)
Database portability, the ability to take a SQL database from a server and move it to a different server even across SQL Server and Azure SQL hosting options, is most often achieved through import and export of bacpac files. Reading and writing the singular bacpac files can be difficult when databases are over 100 GB and network latency can be a significant concern. SqlPackage 162.1 introduced the option to move the data in your database with parquet files in Azure Blob Storage, reducing the operation overhead on the network and local storage components of your architecture.
Data movement in parquet files is available through the extract and publish actions in SqlPackage. With extract, the database schema (.dacpac file) is written to the local client running SqlPackage and the data is written to Azure Blob Storage in Parquet format. With publish, the database schema (.dacpac file) is read from the local client running SqlPackage and the data is read from or written to Azure Blob Storage in Parquet format.
The parquet data file feature benefits larger databases hosted in Azure with significantly faster data transfer speeds due to the architecture shift of the data export to cloud storage and better parallelization in the SQL engine. This functionality is in preview for SQL Server 2022 and Azure SQL Managed Instance and can be expected to enter preview for Azure SQL Database in the future. Dive into trying out data portability with dacpacs and parquet files from the SqlPackage documentation on parquet files.
Microsoft.Build.Sql
The Microsoft.Build.Sql library for SDK-style projects continues in the preview development phase and version 0.1.15-preview was just released. Code analysis rules have been enabled for execution during build time with .NET 6 and .NET 8, opening the door to performing quality and performance reviews of your database code on the SQL project. To enable code analysis rules on your project, add the item seen on line 7 of the following sample to your project definition (<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>).
<Project DefaultTargets=”Build”>
<Sdk Name=”Microsoft.Build.Sql” Version=”0.1.15-preview” />
<PropertyGroup>
<Name>synapseexport</Name>
<DSP>Microsoft.Data.Tools.Schema.Sql.Sql160DatabaseSchemaProvider</DSP>
<ModelCollation>1033, CI</ModelCollation>
<RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
</PropertyGroup>
</Project>
During build time, the objects in the project will be checked against a default set of code analysis rules. Code analysis rules can be customized through DacFx extensibility.
Ways to get involved
In early 2024, we added preview releases of SqlPackage to the dotnet tool feed, such that not only do you have early access to DacFx changes but you can directly test SqlPackage as well. Get the quick instructions on installing and updating the preview releases in the SqlPackage documentation.
Most of the issues fixed in this release were reported through our GitHub community, and in several cases the person reporting put together great bug reports with reproducing scripts. Feature requests are also discussed within the GitHub community in some cases, including the online index operations and blocking table recreation capabilities. All are welcome to stop by the GitHub repository to provide feedback, whether it is bug reports, questions, or enhancement suggestions.
Microsoft Tech Community – Latest Blogs –Read More
Azure Sphere OS version 24.03 is now available for evaluation
Azure Sphere OS version 24.03 is now available for evaluation in the Retail Eval feed. The retail evaluation period for this release provides 28 days (about 4 weeks) of testing. During this time, please verify that your applications and devices operate properly with this release before it is deployed broadly to devices in the Retail feed.
The 24.03 OS Retail Eval release includes bug fixes and security updates including additional security updates to the cancelled 23.10 release, and a bugfix to a sporadic issue with OS update that caused the cancellation of that release.
For this release, the Azure Sphere OS contains an updated version of cURL. Azure Sphere OS provides long-term ABI compatibility, however the mechanisms of how cURL-multi operates, particularly with regard to recursive calls, have changed since the initial release of the Azure Sphere OS. Microsoft has performed additional engineering to provide backward compatibility for previously compiled applications to accommodate these changes. However, this is a special area of focus for compatibility release during this evaluation.
If your application leverages cURL-multi (as indicated by the usage of the `curl_multi_add_handle ()` API) we would encourage you to perform additional testing against the 24.03 OS. These changes do not impact applications that use the cURL-easy interface (as indicated by the usage of `curl_easy_perform()` API.).
Areas of special focus for compatibility testing with 24.03 include apps and functionality utilizing:
cURL and cURL-multi
wolfSSL, TLS-client, and TLS-server
Azure IoT, DPS, IoT Hub, IoT Central, Digital Twins, C SDK
Mutual Authentication
For more information on Azure Sphere OS feeds and setting up an evaluation device group, see Azure Sphere OS feeds and Set up devices for OS evaluation.
For self-help inquiries or technical support, review the Azure Sphere support options.
Microsoft Tech Community – Latest Blogs –Read More
Don’t miss out! Register now for the upcoming Ability Summit, March 7, 2024.
Discover how AI can fuel your accessibility innovation.
How can AI drive inclusion? In this free digital event, you will learn how to unleash human potential with accessible AI. The newest tech can bridge the accessibility divide and we’re bringing together leading experts who have a deep understanding of disabilities in the workplace. Together, we can embed inclusive solutions and improve opportunities for people across the disability spectrum.
Register here!
Microsoft Tech Community – Latest Blogs –Read More
Don’t miss out! Register now for the upcoming Ability Summit, March 7, 2024.
Discover how AI can fuel your accessibility innovation.
How can AI drive inclusion? In this free digital event, you will learn how to unleash human potential with accessible AI. The newest tech can bridge the accessibility divide and we’re bringing together leading experts who have a deep understanding of disabilities in the workplace. Together, we can embed inclusive solutions and improve opportunities for people across the disability spectrum.
Register here!
Microsoft Tech Community – Latest Blogs –Read More
Partner Blog | 2024 Microsoft Partner events
by Nicole Dezen, Chief Partner Officer and Corporate Vice President, Global Partner Solutions
2023 was a year of exciting growth and innovation here at Microsoft. This year’s focus is to empower our customers and partners through AI transformation, and we’re excited to share what will be an impactful lineup of events for 2024. Attending these events provides you with the opportunity to learn, grow, and make defining connections with experts from around the world.
Microsoft Inspire: the next chapter
Continue reading here
Microsoft Tech Community – Latest Blogs –Read More
Partner Blog | 2024 Microsoft Partner events
by Nicole Dezen, Chief Partner Officer and Corporate Vice President, Global Partner Solutions
2023 was a year of exciting growth and innovation here at Microsoft. This year’s focus is to empower our customers and partners through AI transformation, and we’re excited to share what will be an impactful lineup of events for 2024. Attending these events provides you with the opportunity to learn, grow, and make defining connections with experts from around the world.
Microsoft Inspire: the next chapter
Continue reading here
Microsoft Tech Community – Latest Blogs –Read More
Authorization_RequestDenied
Hi team,
We are currently trying to get user email address removed for privacy reasons through the https://graph.microsoft.com/v1.0/users/email address removed for privacy reasons
We get the below error: (Forbidden:Authorization_RequestDenied) Insufficient privileges to complete the operation. Date: 2024-02-28T15:26:23. Request Id: ce9dca50-7dba-44d4-be95-e5a4d14aada0. Client Request Id: ce9dca50-7dba-44d4-be95-e5a4d14aada0.
We have granted the access policy to this user and we do have the correct scopes. Could you look at the logs and let us know what might be the issue here?
Thanks,
Vakul
Hi team, We are currently trying to get user email address removed for privacy reasons through the https://graph.microsoft.com/v1.0/users/email address removed for privacy reasons We get the below error: (Forbidden:Authorization_RequestDenied) Insufficient privileges to complete the operation. Date: 2024-02-28T15:26:23. Request Id: ce9dca50-7dba-44d4-be95-e5a4d14aada0. Client Request Id: ce9dca50-7dba-44d4-be95-e5a4d14aada0. We have granted the access policy to this user and we do have the correct scopes. Could you look at the logs and let us know what might be the issue here? Thanks,Vakul Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
Azure Virtual Network now supports updates without subnet property
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;}
table.MsoTableGrid
{mso-style-name:”Table Grid”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-priority:39;
mso-style-unhide:no;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0in;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Aptos”,sans-serif;
mso-ascii-font-family:Aptos;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Aptos;
mso-hansi-theme-font:minor-latin;
mso-font-kerning:1.0pt;
mso-ligatures:standardcontextual;}
Azure API supports the HTTP methods PUT, GET, DELETE for the CRUD (Create/Retrieve/Update/Delete) operations on your resources. The PUT operation is used for both Create and Update. For existing resources, using a PUT with the existing resources preserves them and adds any new resources supplied in the JSON. If any of the existing resources are omitted from the JSON for the PUT operation, those resources are removed from the Azure deployment.
Based on customer support cases and feedback, we observed that this behavior causes problems for customers while performing updates to existing deployments. This is a challenge in the case of subnets in the VNet where any updates to the virtual network, or addition of resources (e.g. adding a routing table), to a virtual network require you to supply the entire virtual network configuration in addition to the subnets. To make it easier for customers, we have implemented a change in the PUT API behavior for virtual network updates. This change allows you to skip the subnet specification in a PUT call without deleting the existing subnets. This capability is now available in a Limited Preview in all the EUAP regions, US West Central and US North with API version 2023-09-01.
Previous behavior
The existing behavior has been to expect a subnet property in the PUT virtual network call. If a subnet property isn’t included, the subnets are deleted. This might not be the intention.
New PUT VNet behavior
Assuming your existing configuration is as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “SubnetB”,
“properties”: {…}
},
{
“name”: “SubnetC”,
“properties”: {…}
},
{
“name”: “SubnetD”,
“properties”: {…}
}
]
The updated behavior is as follows:
If a PUT virtual network doesn’t include a subnet property, no changes to the existing set of subnets is made.
If subnet property is explicitly marked as empty, we will treat this as a request to delete all the existing subnets. For example:
“subnets”: []
OR
“subnets”: null
If a subnet property is supplied with specific values as follows:
“subnets”: [
{
“name”: “SubnetA”,
“properties”: {…}
},
{
“name”: “Subnet-B”,
“properties”: {…}
},
{
“name”: “Subnet-X”,
“properties”: {…}
}
]
In this case, the following changes are made to the virtual network:
SubnetA is unchanged. Assuming the supplied configuration is the same as existing.
SubnetB, SubnetC and SubnetD are deleted.
Two new subnets Subnet-B and Subnet-X are created with the new configuration.
This behavior remains unchanged from what Azure currently has today.
Next Steps
Test the new behavior in the regions listed above and share your feedback.
Microsoft Tech Community – Latest Blogs –Read More
