Important Notice: Breaking Changes Due to Public Key Update

[llali]

Important Notice: Breaking Changes Due to Public Key Update

We would like to inform you about an important change in DacFx NuGet, starting version 170.0.27-preview, that may impact your applications. We have updated the public key in the DLLs included in this package. This change is crucial for enhancing the security and integrity of our assembly but may cause breaking changes in your C# applications.

Impact of Public Key Change

• Build Failures: Applications referencing the old DLL with the previous public key will fail to build.
• Runtime Errors: Applications may experience runtime errors if the old DLL is loaded dynamically or through reflection.
• Configuration Updates: Any configuration files or settings that reference the old public key will need to be updated to the new key.

Steps to Address the Change

To mitigate the impact of this change, we recommend the following steps:

• Update Package References: Ensure that you update your NuGet package reference to the latest version that includes the DLL with the new public key.
• Rebuild Your Application: Rebuild your application to ensure it correctly references the new DLL.
• Thorough Testing: Conduct comprehensive testing to identify and resolve any issues resulting from the public key change.
• Update Documentation: Ensure that all relevant documentation and configuration files are updated to reflect the new public key.

Support and Assistance

We are committed to providing you with the necessary support during this transition. If you encounter any issues or need further assistance, please do not hesitate to contact our team at DacFx github

[ErikEJ]

Would be nice to know which "package" and exact version this refers to!

[llali]

Added the version of number of the package that has this breaking change. 170.0.27-preview

[HamsterExAstris]

Is there a preview version of sqlpackage available using a version of DacFx with the new key? It would be helpful to test and understand how this impacts deployment contributors.

(This will almost certainly break old contributors on .NET Framework, but it's possible the .NET 8 version won't be impacted. Not that that's necessarily a solution, since the standard Azure Pipelines/Github Actions runner images include the .NET Framework version of the app.)

[ErikEJ]

@HamsterExAstris yes: https://www.nuget.org/packages/Microsoft.SqlServer.DacFx/170.0.27-preview - what do you mean by "the app" ?

[HamsterExAstris]

@ErikEJ I mean sqlpackage, Microsoft's CLI wrapper application for DacFx. It appears to be supported by the DacFx team; the documentation directs feedback to this repository.

It has the ability to load user-provided "deployment contributors" at runtime, which are .NET assemblies built against the Microsoft.SqlServer.DacFx NuGet package. It would be helpful to be able to evaluate how this change will impact those.

EDIT: Okay, found the note in the docs about where the .NET 8 preview version can be found, so at least one of the two versions can be tested. It would still be helpful if a preview of the .NET Framework version was available too.

[ErikEJ]

@HamsterExAstris Got it.

Agree a .NET Framework preview would be helpful - I think it is much more likely to be impacted.

[llali]

@HamsterExAstris I'll provide a preview version of sqlpackage for .Net Framework in coming days.

[llali]

@HamsterExAstris @ErikEJ here's a preview version for sqlpackage.exe .Net Framework. Please let me know if you find any issues. https://github.com/microsoft/DacFx/releases/tag/170.0.33-preview

[HamsterExAstris]

@llali Thanks. I've confirmed that the changing the key did break .NET Framework deployment contributors built against the old NuGet package.

Microsoft.Data.Tools.Diagnostics.Tracer Verbose: 0 : 2025-01-21T20:01:45 : SafeDirectoryCatalog: Extensibility failed to load DLL '[contributor DLL path]' due to an exception. Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

I don't think that's necessarily a reason to stop the change, as there are workarounds for both Azure Pipelines and GitHub Actions.

For GitHub Actions' Azure/sql-action action, they'd need to preinstall a known version to guarantee a consistent environment. That action supports the .NET Core version as a global tool, though, so doing so is much simpler than in Azure Pipelines. Install a fixed version of sqlpackage in the workflow, and it should be consistent regardless of what's preinstalled on the runner.

The Azure Pipelines SqlAzureDacpacDeployment@1 task only supports the .NET Framework version of sqlpackage. Since Microsoft-hosted agents won't be upgraded instantly (images with 162.* and 170.* will co-exist temporarily), I think that pipelines using a deployment contributor would need to build it against the 170.* NuGet package, and then explicitly install the 170.* MSI before using the SqlAzureDacpacDeployment@1 task, to guarantee a consistent environment.

The SqlPackage in development pipelines page includes instructions on upgrading if needed, so I think users have all the tools they'd need to configure their pipelines in a manner compatible with this change. (And deployment contributors are pretty niche to start with.)

[llali]

@HamsterExAstris Thanks for testing this. to make sure I understand the scenario correctly, you have deploy-contributors dlls, built with DacFx 160 and now using sqlpackage 170, the deploy-contributors are not loaded? I assume this is not related to the signing key. With the vbump I assume contribution dlls are required to be built with 170 as well. can you please confirm if you build the deploy-contributors with 170 and still sqlpackage cannot load them? Thanks again for your help

[HamsterExAstris]

@llali

Thanks for testing this. to make sure I understand the scenario correctly, you have deploy-contributors dlls, built with DacFx 160 and now using sqlpackage 170, the deploy-contributors are not loaded?

That is correct. (Specifically, not loaded by the .NET Framework version of sqlpackage. I did not test with the .NET Core version, since it's not supported by the Azure Pipelines task.)

Since the public key is changing, I believe this is expected behavior.

With the vbump I assume contribution dlls are required to be built with 170 as well. can you please confirm if you build the deploy-contributors with 170 and still sqlpackage cannot load them?

If I rebuild against 170, the contributor loads correctly.

However, during the period of time when the 170 update is rolling out to the Microsoft-hosted agents, a given Azure Pipelines agent could have either 162 or 170 installed; it's not a hard cutover. And unfortunately it doesn't appear possible to create a single contributor that works with both versions.

Once 170 is released, pipelines using deployment contributors on Microsoft-hosted agents will want to explicitly install 170 at the start of their work, to put it into a known state. (The documentation already covers how to do this, as linked above.)

With 162, I did not have to match the specific sqlpackage version (other than 162.3.563 which was a bug that was fixed in 162.3.566). I thought assemblies for older majors worked in 162 as well, but I'm not in a position to explicitly retest that (and won't be for ~2 weeks). However, sqlpackage ships with binding redirects that look to me like they enable this scenario.

None of this is intended to necessarily be "I think the DacFx team should do something different"; I mainly wanted to lay out how to work around the upcoming issues with deployment contributors in Azure Pipelines in case we're not the only users.