ASP.net stack trace line numbers

[Aldous]

I use the enterprise library exception handling block to email myself any errors that occur within my ASP.NET application. I have an app that is running perfectly. As soon as I deploy it to the production server, I get a stack trace output that looks like this. All is okay on my development machine. It reports the line number in the source where the exception was raised. This info is read from the Exception.StackTrace property. However, when I deploy the same exact executable files to the web server, I no longer get the source file and line number information.

[PARRISH]

I'm not familiar with how to set this up for web remote deployments, but if you have control over what shows up in the email, then look at

System.Exception.StackTrace

The cmp instruction is one of those things I noticed that always appeared when there is a callvirt in IL. VB uses a call at times instead of a callvirt and the cmp doesn’t appear then.

[Alejandro]

In my solution I created my own Build Configuration. Visual Studio ships with two by default; Debug and Release. When the app is running in debug mode, which you'll have to specify in web.config (the entire web.config schema is actually listed somewhere on MSDN, don't have the link handy). You must be neede a configuration to sit between those two, so I created DEV. For local development I would use Debug, I would deploy to my test server using DEV, and when it comes time to publish it to my host I'll use Release.

[Timothi]

as a security feature, ASP.NET on IIS gives a generic error message on HTTP 500 to clients other than localhost, and only displays the error message/stack trace to requests from localhost. That is the part I don't understand, it should show me the line number since it was compiled for debug and symbols for other libraries are there.Right-click each project -> Properties -> Build Tab. Check Define DEBUG constant and Define TRACE constant.
Click Advanced button and set Internal Compiler Error Reporting to prompt and Debug Info: to full.

[jimbob2001]

Actually the cause of your problem and its solution is simple. StackTraces in .NET contain the function name internally and are able to describe the actual stack trace at runtime. This is influenced by optimizations (where some functions are inlined) so you could see a different StackTrace from a Debug and Retail build. However, ultimately the key is that only the PE file (.exe or .dll) is needed to reconstruct the function name in a Stack Trace. However, line numbers and file names are a different animal. They are only contained in the .pdb file produce by the compiler. If this file is present it will be used to locate the line number and file name, if not that information will not be present. The reason you are not seeing the line number and file name in your stack traces is that in production you are missing the .pdb file. I however, strongly recommend that you never deploy your .pdb files to production because it is a security risk, however, the removal of that information is not being done by the framework or ASP.NET, it is rather simply a byproduct of .pdb files not being present when the exception occurs.