If you write code to SQL Server then you might be interested in this: at the end of 2017 I wrote a tSQLt tdd training course which has helped over 300 people learn both tSQLt and how to apply TDD practices to their SQL Server T-SQL development, you can join the course at https://courses.agilesql.club. The course is free if you are happy to wait 10 weeks to complete it, with 1 lesson being made available per week - if you are in more of a hurry or you would like to help support the project you can purchase the course which makes it instantly available to you.
I have noticed that these cmd files are missing from recent ssdt builds, to enable logging see Kevin’s comment:
I was helping someone get a deployment filter working in SSDT recently and the issue was that they had configured the publish profile to include filter but when they did a publish or generate script, an error occurred with no more detail than “Contributor initialization error.”:
Being stuck at what to do next I had a poke around and found the SsdtTrace.cmd in the Dac folder:
c:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\SQLDB
When you run it from the command line you get these options:
- SsdtTrace.cmd start DacFx.etl Ssdt.etl
- SsdtTrace.cmd stop
- SsdtTrace.cmd view DacFxOrSsdt.etl
I went ahead, some may say foolishly, and went with “SsdtTrace.cmd start DacFx.etl Ssdt.etl” which failed as I was not running the command window as an administrator:
I then retried from an admin command prompt and then retried the publish and somewhat unsurprisingly I still got the same “Contributor initialization error.” so I went back to SsdtTrace and stopped the traces. The traces were stopped and then I used to two view commands:
- SsdtTrace.cmd view DacFx.etl
- SsdtTrace.cmd view Ssdt.etl
after running each command I got a message to say an output file had been generated, whoop whoop:
This gives you an xml file with messages about what happened when you run the trace, you can view it in any browser and although pretty verbose is pretty easy to understand and see if you get any errors.
Because the results of running a trace are standard etl files you can also use the event viewer to view the trace which gives a slightly nicer ui.
So there you have it an easy way to get a log of what happens when you do something in SSDT, I don’t think that this is going to help everyone fix every issue but if you are really stuck then it might help - it should also help if anyone wants to use ahem reflector ahem to study how the DacFx works etc.
If anyone does find anything really useful in these logs please share!