0

I am using the BuildManager.Build method to build a SQL Server Data Tools/Data-Tier Application Framework/Visual Studio Database Project. The same project, when built in the same configuration manually via Visual Studio builds without exception and in a relatively short period of time, about 10 seconds. However, when built programatically via BuildManager.Build, I encounter a whole slew of first chance exceptions, all of which seem to occur in the antlr namespace. This makes the build process extremely slow. Is this occurring because the program that is executing BuildManager.Build is running in debug mode? Does anyone know how to get rid of the first chance expections and hopefully speed up the build process?

Dan Forbes
  • 2,734
  • 3
  • 30
  • 60

1 Answers1

1

The first chance exceptions are thrown in both cases it is just when you are doing it, for some reason, you are attached as a debugger to the child process which causes the process to freeze for each exception, pass control to your process which probably ignores it and restarts the app - running as a debugger when there are lots of first chance exceptions is very very slooooooooooooooow.

The exceptions are thrown because SSDT uses Antlr (as you have probably guessed) to parse the T-SQL and it has found something it doesn't like.

The key to this is finding out why you are attached as a debugger, is that normal with BuildManager.Build?? The msdn article isn't particularly helpful. If you can find a way to run the build without attaching as a debugger it will get it back to normal speed.

FYI - The release / debug build shouldn't make any difference in this case.

Ed Elliott
  • 6,666
  • 17
  • 32
  • This is definitely the answer. There's no question, though, as to why I was attached as a debugger. My console app is in active development, and I'm running each step through the debugger to ensure that things are happening as I would expect. When I compiled the code and ran it from the command line, things happened much faster...on par with what I would expect. Thanks for your response! – Dan Forbes Mar 18 '15 at 14:40
  • That is great news! I have written my own tools using the script dom (the slow bit under a debugger) and it is so much slower and more painful. – Ed Elliott Mar 18 '15 at 15:40