after more than a day of research plus trial & error I found, that the files belonging to the DacPacReport task contained in the latest version of your extension (1.4.152) in the marketplace differ quite a lot from the files that the build agent downloads to its workspace.
Due to that, we cannot use the new task argument "userSqlPackagePath" that you introduced with the latest version, as it is missing in our UI for the task in Azure DevOps 2020.1. And the old detection mechanism (w/o the Find-Files function looking for vswhere.exe) fails to find anything newer than the VS 2013 version on our build server - despite the fact, that we have VS 2017 and VS 2019 installed with the DacMsi extension available (and appropriate versions of sqlpackage.exe, of course).
I could not identify the reason, why the detection of newer VS versions of sqlpackage.exe fails, unfortunately. So my last action was, that I replaced the following files of version 1.2.178 of the DacPac module in the workspace of one of our build agents' workspace:
all .ps1, .json, .xslt files in the _work_tasks\DacPacReport_1ebf2967-63b3-4372-89f7-6799108a22f0\1.2.178 folder
all files in the _work_tasks\DacPacReport_1ebf2967-63b3-4372-89f7-6799108a22f0\1.2.178\ps_modules\VstsTaskSdk folder
After that, I modified DacPacReport.ps1, line 14
from
$userSqlPackagePath = Get-VstsInput -Name "userSqlPackagePath"
to
$userSqlPackagePath = ""
Doing so the task found at least the VS 2017 version of sqlpackage.exe, and works as expected, producing the reports.
After that, I modified DacPacReport.ps1, line 14
from
$userSqlPackagePath = Get-VstsInput -Name "userSqlPackagePath"
to
$userSqlPackagePath = "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\150\sqlpackage.exe"
Now, the DacPacReport tasks also runs and works as expected, but is now using the VS 2019 version of sqlpackage.exe and also producing the reports we're heavily relying on.
So my question is:
Could you please compare the current files in the extension for the DacPacReport task with your latest versions here in the code repo, and if you find the same issue, replace the files in the extension with the new one's, re-generate the extension, and upload it with a newer version to the marketplace?
This would probably also a good chance to extend the argument of the call to vswhere.exe with the version number of VS 2022 (i.e. 17.0).
Your timely support would be highly appreciated! If you need any more information from me in order to solve this, just let me know.
Best regards,
Franz
P.S.: it would help a lot if you could mention in the Readme, that the path to vswhere.exe needs to be added to the PATH environment variable in order to be found/used by your task (using FindSqlPackagePath.ps1).
@colindembovsky
Dear Colin,
after more than a day of research plus trial & error I found, that the files belonging to the DacPacReport task contained in the latest version of your extension (1.4.152) in the marketplace differ quite a lot from the files that the build agent downloads to its workspace.
Due to that, we cannot use the new task argument "userSqlPackagePath" that you introduced with the latest version, as it is missing in our UI for the task in Azure DevOps 2020.1. And the old detection mechanism (w/o the Find-Files function looking for vswhere.exe) fails to find anything newer than the VS 2013 version on our build server - despite the fact, that we have VS 2017 and VS 2019 installed with the DacMsi extension available (and appropriate versions of sqlpackage.exe, of course).
I could not identify the reason, why the detection of newer VS versions of sqlpackage.exe fails, unfortunately. So my last action was, that I replaced the following files of version 1.2.178 of the DacPac module in the workspace of one of our build agents' workspace:
After that, I modified DacPacReport.ps1, line 14 from
$userSqlPackagePath = Get-VstsInput -Name "userSqlPackagePath"to$userSqlPackagePath = ""Doing so the task found at least the VS 2017 version of sqlpackage.exe, and works as expected, producing the reports.
After that, I modified DacPacReport.ps1, line 14 from
$userSqlPackagePath = Get-VstsInput -Name "userSqlPackagePath"to$userSqlPackagePath = "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\150\sqlpackage.exe"Now, the DacPacReport tasks also runs and works as expected, but is now using the VS 2019 version of sqlpackage.exe and also producing the reports we're heavily relying on.
So my question is: Could you please compare the current files in the extension for the DacPacReport task with your latest versions here in the code repo, and if you find the same issue, replace the files in the extension with the new one's, re-generate the extension, and upload it with a newer version to the marketplace? This would probably also a good chance to extend the argument of the call to vswhere.exe with the version number of VS 2022 (i.e. 17.0).
Your timely support would be highly appreciated! If you need any more information from me in order to solve this, just let me know.
Best regards, Franz
P.S.: it would help a lot if you could mention in the Readme, that the path to vswhere.exe needs to be added to the PATH environment variable in order to be found/used by your task (using FindSqlPackagePath.ps1).