[SOLVED] Schema Compare and SqlPackage 150 case sensitivity issues

Schema Compare and SqlPackage 150 case sensitivity issues

So I installed the new SqlPackage 150 (having had 140 before with no issues) and deploying the database twice (sqlpackage is a joke, this twice needs to be done on any update to see what new quirks it has when it alters untouched code), I noticed it's altering functions even if no changes occurred in actual code. Having had trouble before with SqlPackage and it's very poorly designed comparison methods, I learned to workaround them:

don't use iif, use case
keep entire case when then ... end on a single line no matter how long it is
always wrap in parenthesis (default values) and (computed fields)
name all constraints (pks, uniques, checks)

Today, something new came up. All my sql code is written in lower-case and all names are quoted [name], so it is clean like: create function [dbo].[fnFunction1](...). But new SqlPackage decided to alter ALL my functions. Not procedures, not tables, not views, not triggers even if all are written in lower-case create *. I tried to publish 3 times, same thing. Only functions are altered, always.

So I ran Schema Compare to see what is the problem. That's how I previously found the quirks of sqlpackage I listed before, through trial and error. I looked at the differences and always there is a single difference:

local code has create function ...
remote code has CREATE function ...

Yes, I do have Ignore keyword casing checked in Schema Compare options and in the Publish Profile in the SSDT Project. It seems to be irrelevant in functions.

The difference in casing causes the functions to be altered but nothing else even if I always use (and have always used) create in lower-case. So remotely it wants CREATE function while locally it has create function. While create table\view\procedure\trigger\index\... is cool.

What is happening here? I really don't want to change the functions casing, also I don't want to alter on every publish, also don't want to revert to SqlPackage 140.

Issue did not happen using SqlPackage140 with SqlServer 2019 but occurs on SqlPackage150 with SqlServer 2019.

Solution

This behavior has been fixed with the latest SQLpackage. But it did not update itself, I had to do it myself manually.

[EDIT] Wrote a PowerShell script to auto-update so I can run it every now and then and it does the work for me. (I'm new to PS so... it might be bad, but it works.)