Last post Apr 05, 2017 12:01 PM by PatriceSc
Mar 28, 2017 12:11 PM|justKiran|LINK
We have web application in asp.net 4.0. We wanted to log the detail exceptions with class name, method name and line number in production environment. The below code works fine in debug mode. When we publish it does not display line numbers in stack trace.
I tried with no success, copying .pdb file in bin folder, advanced compile option with full mode debug, removing temporary asp.net files, debug=true in web.config etc.
HttpException lastErrorWrapper = Server.GetLastError() as HttpException;
Exception lastError = lastErrorWrapper;
if (lastErrorWrapper.InnerException != null)
lastError = lastErrorWrapper.InnerException;
System.Text.StringBuilder oExceptionString = new System.Text.StringBuilder();
oExceptionString.Append(" Error Type Name : " + lastError.GetType().ToString());
oExceptionString.Append(" Error Message : " + lastError.Message.ToString());
oExceptionString.Append(" Error Trace: " + lastError.StackTrace.ToString());
I appreciate any suggestions and alternate solution
Mar 28, 2017 01:40 PM|PatriceSc|LINK
http://stackoverflow.com/questions/628565/display-lines-number-in-stack-trace-for-net-assembly-in-release-mode (but note that it comes accross code optimization).
I never really bothered. In my experience the line number is not that usefull especially if you avoid to create large methods. Another option might be to use
https://www.codeproject.com/tips/661604/get-caller-method-name-line-num (this is not to get the exact line but you could add few trace calls inside a long method to narrow down where it happens. Try to get an exact line number would be really my very last
Apr 01, 2017 11:28 AM|justKiran|LINK
Thank you for your information. Previously I had tried with given link of stackoverflow, but it does not display line numbers in stack trace in release mode though we uncheck optimization and copy .pdf file in bin folder.
The second option might work. However, in our case the application has 4 class library projects and code is huge. Also most of the code does not have try catch block. so tracing and breaking down every method would be time consuming. Hence I was thinking
to get the line numbers, file path and trace info in global.asax application error event.
If this gives us less information, How can we diagnose clients error at our end without their database at our end ?
Apr 05, 2017 12:01 PM|PatriceSc|LINK
AFAIK deploying PDB files is supposed to work (unless it has been changed since then ?). You could also try perhaps http://www.lionhack.com/2014/01/28/stack-trace-line-numbers-without-deploying-pdbs/ From
a quick read, the idea seems to deploy just the needed information rather than actual PDB files.
I was about to say that you could keep PDB files on your own machine and do the same thing but it made me think that you might be able to use the
https://msdn.microsoft.com/en-us/library/f7dy01k1(v=vs.110).aspx tool to get the line that matches an offset (note though that code optimization might change this a bit so take this
rather as an indication of the area of interest rather than really as being the exact line). If I remember VS (maybe Enterprise) even have a window where you should be able to see those IL offsets.
You really have long and complex methods (which is a bad practice anyway)? If not used yet to debugging, give this a try and with some experience, you'll see that it's not that difficult to narrow down the relevant portion of code based on the error that
happens. It's really rare that I need to add some trace information to narrow down a bit where it happens exactly inside a method (and when it happens it rather more to trace more stuff to better understand what happens in a difficult case rather than really
to find the exact location). I'll perhaps try the next time though to check of the IL offset could be usefull. Thanks ;-)