在TeamCity 7构建服务器上构建* .sqlproj SSDT项目时，*。dacpac文件的文件命名错误

Question

We have an MSBuild task that builds our *.sqlproj file, the output of which is loaded back into TeamCity as an artifact for subsequent deployment.

Similar to this user, we are having some unpredictable output file naming happen: Invalid file names when trying to deploy SSDT project with TeamCity 8

It appears that sometimes, it produces this output file under /bin/Release:

MyProj.sqlproj.dacpac

Then subsequent builds produce this file in the same folder:

MyProj.dacpac

We haven't done indepth testing yet - I was wondering if anyone else has seen similar or has a suggested troubleshooting path?

To be clear, it's the same task, running the same command against the same project - just run repeatedly overtime as new checkins happen.

Answer 1

Sounds like you have conflicting .sqlproj files being checked in.

I'd start by checking the history.

Answer 2

Well, after looking more closely at the build log I could see that the TeamCity MSBuild runner appears to be creating some temporary virtual project files (or something, I don't know for sure because they get deleted) with names like:

MyProj.sqlproj.teamcity

I theorized that this may be confusing MSBuild or one of the targets related to building dacpacs, so I replaced the TeamCity MSBuild build step with a Command Line build step that calls MSBuild on the original project file itself, and this appeared to solve the problem. It now produces the dacpac with the file I'm expecting.

I don't have time to dig further now, but I could believe that there's some logic in the chain somewhere that is deriving the name for the final *.dacpac from the name of the project file being used. My guess is that it just strips off everything after the last "." and attaches the ".dacpac" suffix.

I don't fully know why it would occasionally create a *.dacpac file with the correct name, but I was at times doing a manual build in the TeamCity agent work folder from the commandline on the build server itself, so this may have just been a file leftover from previous executions.