Skip to content

Conversation

@ErikEJ
Copy link

@ErikEJ ErikEJ commented Mar 26, 2024

fixes #1225

Description: Look for SqlPackage.exe presence and version in the Visual Studio DAC folder introduced in later VS versions

Documentation changes required: N

Added unit tests: N

Attached related issue: #1225

Checklist:

  • Version was bumped - please check that version of the extension, task or library has been bumped.
  • Checked that applied changes work as expected.

Verified with

. "$PSScriptRoot/SqlPackageOnTargetMachines.ps1"
Get-SqlPackageOnTargetMachine

ErikEJ added 2 commits March 26, 2024 10:53
fixes microsoft#1225

tested and confirmed locally with:

. "$PSScriptRoot/SqlPackageOnTargetMachines.ps1"

Get-SqlPackageOnTargetMachine
@ErikEJ
Copy link
Author

ErikEJ commented Mar 26, 2024

@dzsquared FYI! Please have a look 😄

@b3go
Copy link

b3go commented Mar 26, 2024

Tested and works for 2019 and 2022. Output:

PS C:\WINDOWS\system32> Get-SqlPackageOnTargetMachine
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\150\SqlPackage.exe
PS C:\WINDOWS\system32> Get-SqlPackageOnTargetMachine
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\SqlPackage.exe

@ErikEJ
Copy link
Author

ErikEJ commented Mar 26, 2024

@b3go Thanks for confirming!

@ErikEJ
Copy link
Author

ErikEJ commented Mar 26, 2024

@dzsquared wonder if this is enough to also affect the azuresqldeployment task?

@ErikEJ
Copy link
Author

ErikEJ commented Mar 26, 2024

Looks like there is duplicate code in another repo: https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks%2FSqlAzureDacpacDeploymentV1%2FFindSqlPackagePath.ps1#L348-L352

@dzsquared
Copy link

Often the version from the dac.msi installer (C:\Program Files\Microsoft SQL Server\160\DAC\bin) will be newer than the VS version, causing it to be selected over the VS version - probably in part why we haven't seen this behavior crop up much.

Just fyi - the version in azure-pipelines-tasks has another PR open on it to enable more versatility - microsoft/azure-pipelines-tasks#19648

Finally, the dotnet tool version of Sqlpackage was mentioned by @b3go and indeed we're hoping to integrate it with these tasks in the future - but this change doesn't need to be held up for that larger adjustment.

thank you @ErikEJ!

@ErikEJ
Copy link
Author

ErikEJ commented Mar 27, 2024

probably in part why we haven't seen this behavior crop up much.

Ah, that's why there have been no issues from hosted agents.

@PaulVrugt
Copy link

Looks like there is duplicate code in another repo: https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks%2FSqlAzureDacpacDeploymentV1%2FFindSqlPackagePath.ps1#L348-L352

I'm a bit confused. We are using the SqlAzureDacpacDeployment@1 task, and it seems to take the C:\Program Files\Microsoft SQL Server\160\DAC\bin sqlpackage version over the visual studio one, even if the visual studio one is newer. Which caused microsoft/DacFx#427 for us. It seems that this PR doesn't fix this issue. But is there an active PR somewhere to fix the SqlAzureDacpacDeployment@1 as well?

@ErikEJ
Copy link
Author

ErikEJ commented Mar 27, 2024

@PaulVrugt Are you still affected by this - I think the version in C:\Program Files\Microsoft SQL Server\160\DAC\bin has been updated on all the Hosted agents now. But I still plan to do a PR in the other repo (to at least align the logic)

@ErikEJ
Copy link
Author

ErikEJ commented Mar 27, 2024

@dzsquared @PaulVrugt Gave up on the other task, too many moving parts

@PaulVrugt
Copy link

@PaulVrugt Are you still affected by this - I think the version in C:\Program Files\Microsoft SQL Server\160\DAC\bin has been updated on all the Hosted agents now. But I still plan to do a PR in the other repo (to at least align the logic)

Well yes, because we are not using hosted agents, we use private agents. Once I updated visual studio on the private agent image, the error started appearing. We now fixed it by updating sqlpackage on the private agent manually, but this would have been prevented if the task worked properly and found the sqlpackage of visual studio (which was updated with the visual studio update)

@ErikEJ
Copy link
Author

ErikEJ commented Mar 27, 2024

@PaulVrugt Got it!

I encountered multiple issues trying to fix the other task:

@PaulVrugt
Copy link

@PaulVrugt Got it!

I encountered multiple issues trying to fix the other task:

Lol. Ok so in summary:

  • The SqlAzureDacpacDeploymentV1 task seems completely broken as it comes to finding the correct sqlpackage
  • You gave up on fixing this due to the moving parts

Well, thanks at least for trying. We'll create our own safeguards to keep sqlpackage.exe up to date at the location SqlAzureDacpacDeploymentV1 IS finding it

@ErikEJ ErikEJ closed this Jan 2, 2025
@b3go
Copy link

b3go commented Mar 17, 2025

I am a bit late but @ErikEJ why did you decide to close this PR? This PR doesn't affect the SqlAzureDacpacDeploymentV1 but would fix the SqlDacpacDeploymentOnMachineGroupV0

@ErikEJ ErikEJ reopened this Mar 17, 2025
@ErikEJ
Copy link
Author

ErikEJ commented Mar 17, 2025

@b3go Reppened, I closed because no reviewers seemed to care.

@b3go
Copy link

b3go commented Mar 17, 2025

seems @dzsquared unfortunately does not have the necessary permissions 😅

@dzsquared
Copy link

a revamp of the ADO task/tasks for SQL projects is planned for the coming months, so while I don't have permissions to influence the v1 code we're keeping tabs on the needs everyone raises (like here) to make v2 a big improvement
:)

@ErikEJ
Copy link
Author

ErikEJ commented Mar 17, 2025

@dzsquared Sounds great, let me know how I can help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: SqlPackageOnTargetMachines.ps1 isn't able to find sqlpackage.exe from Visual Studio installation

4 participants