Have you looked closely at the connection string and any other application-specific configuration data that varies depending on debug or release? Are there other applications successfully using the same server in production (I assume so)? Was the application changed prior to the failure? If so, then what was changed?
What's the secret sause in debug builds?
We have an Entity Framework 6 console application that's started failing in production. It's running against SQL Server 2016 Standard. The stage environment still works, with no errors.
Here's the weird part. If I compile debug, it works like a charm. If I compile GCRelease (the release build for the server that's failing.), it fails. I have DEBUG and TRACE set, I've turned off optimizations, and I'm building with full debugging information. Doesn't matter, it still fails.
I turned on SQL Logging, to see where it was failing, and it's during execution of a stored procedure.
Here's what happens with the debug build;
4/9/2021 9:50:53 AM:-- Executing at 4/9/2021 9:50:53 AM -05:00
4/9/2021 9:50:55 AM:-- Completed in 1447 ms with result: SqlDataReader
GCRelease
4/9/2021 9:41:51 AM:-- Executing at 4/9/2021 9:41:51 AM -05:00
4/9/2021 9:44:51 AM:-- Failed in 180214 ms with error: Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
So, what's debug doing differently, and how can I get the compiler/linker to let me do that with other builds?
2 answers
Sort by: Most helpful
-
-
Swaim,Michael P 1 Reputation point
2021-04-09T19:11:11.58+00:00 Everything's the same except for the exe and dll. I'm literally copying the binaries from the build directories into the production directory, so all connection strings are the same. The application hadn't been updated this year, before it started failing.
Dozens of other applications use the same database without problems.