Another quick bulletin about the changes I made to PoshSSDTBuildDeploy today -
I’ve been dogfooding PoshSSDTBuildDeploy pretty much constantly on a project I’m currently on, which accounts for the fairly active changes being made since April. And recently we changed the account we deployed with from a SQL Login to an AAD account. The change has gone fairly well, with two issues - the first I blogged about here.
The second issue is that we noticed that login failures when deploying via our local scripts to Azure weren’t being properly captured. We knew this because after the script failed we had to run
$error | Format-List -Force to see just what the actual error was, which was this -
Exception : System.Management.Automation.MethodInvocationException: Exception calling "Publish" with "3" argument(s): "One or more errors occurred." ---> System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> AdalException: AADSTS70002: Error validating credentials. AADSTS50126: Invalid username or password Trace ID: 6c352a86-42c3-4821-a4e5-1b3bb3018000 Correlation ID: f6c86cc2-5737-4326-8a57-75bb237f1945
If we look at my initial change from this morning, we can see that I was only capturing
[DacServicesException] type exception, and this was not helpful in this scenario because it is not of this type at all. So I went brute force and got the whole exception message. But because I don’t want to cause a sea of red, I’ve tidied it up a little bit to capture all inner exception messages.
Prior to my change, the error above was only outputting as below; it did not show us the root cause.
: System.Management.Automation.MethodInvocationException: Exception calling "Publish" with "3" argument(s): "One or more errors occurred."
All this now means that exceptions are being handled in a less elegant way but we’ve got a better chance to find the route cause, even if we do run the risk of being hassled by red errors.