I’m porting over a project I created a couple years ago in VS 2005 to VS 2008 in preparation for a major front-end upgrade. So far the process has been pretty painless, but have run into huge problems today with my custom MSBuild scripts that build the database. These utilize a series of simple custom MSBuild tasks I wrote such as OsqlFile, DropTable, GrantExec, etc. which have worked darned near flawlessly thus far.
In VS2008, I’m getting exceptions that look like they are encoding-related, such as “Incorrect syntax near ‘X'” (the Greek letter eta), or “Incorrect syntax near “Y” (some double-dotted i character). Totally wild. I tried saving in a couple different codepages with no luck. The SQL runs just fine in SQL Management Studio. I even took the opportunity to upgrade my old OsqlFile task to SqlCmdTask, but no luck. I don’t think the task is even getting called at all — something about MSBuild is working against me here. However, other of my custom tasks (DropTable for one) DO work.
- I’ve checked the encodings in TextPad and both the .build file and the .sql file are UTF-8, no BOM.
- Running the exact same command line as the MSBuild custom task is running (SQLCMD.EXE plus options) works from the VS 2008 command prompt.
So I fired up profiler, and guess what? Look here:
Those little BOMs (I assume that’s what they are) that start with the “greek eta” character are getting passed in from MSBuild to SQL Server, via SQLCMD. Strange that the same command works outside of MSBuild.
So I attempted to force SQLCMD to use the right codepage with the -f 65001 option, which didn’t work. However, forcing VS 2008 to save the .sql file in codepage Windows 1252, and forcing SQLCMD to use 1252 via the -f option, worked!
What a hunk of junky junk. How about a little piece of code, like 10 lines long, that mediates codepage conflicts in EVERY piece of software. Hm….
Real odd: TextPad 5.1 is still showing the .sql file as UTF-8 encoded, even though it’s Windows 1252. Also, TextPad never showed me the BOMs in the original 65001-encoded version.
UPDATE: it turns out that if I save the files as Unicode codepage 1200 both SqlCmd.exe and Osql.exe work, no matter what I set the encoding to with the -f option. Both -f 65001 and -f 1200 work against those files. TextPad is now reporting “Unicode” encoding instead of “UTF-8” encoding.
UPDATE 2: I find encoding stuff to be about as fun as flossing.