0

I've gone to some lengths to improve the error handling in my webservice - in particular, showing the StackTrace as in this example:

catch (Exception ex)
        {
            EventLog log = new EventLog();
            log.Source = g_EventSource;
            StringBuilder msg = new StringBuilder("Exception in UpdateRecord method has been logged:");
            msg.Append(Environment.NewLine);
            msg.Append("passedURL="); msg.Append(passedURL);
            msg.Append(Environment.NewLine);
            msg.Append(ex.Message);
            msg.Append(Environment.NewLine); 
            msg.Append(ex.Source);
            msg.Append(Environment.NewLine);
            msg.Append(ex.StackTrace);
            log.WriteEntry(msg.ToString(), EventLogEntryType.Error, 100);
            return msg.ToString();
        }

My question is what will happen when I publish my webservice having compiled it as RELEASE instead of DEBUG? I only publish the .dll and the web.config (no source) now when I compile in DEBUG mode but when an error is logged the StackTrace points back to line numbers of file(s) in my development machine like: 

C:\Documents and Settings\johna\My Documents\Visual Studio 2008\Projects\   etc.

In short, will a RELEASE mode DLL still show the above sort of stack trace? I think it will but not sure; my system administrator has raised this question as we prepare for a move into another level of deployment.

John Adams
  • 4,573
  • 23
  • 85
  • 124
  • You should output ex.ToString() rather than outputting pieces. It will not only show the complete trace, it will also take into account traces across AppDomains and across remoting boundaries. This can be important even if you are not using remoting "by hand", as .NET sometimes uses it internally. – John Saunders Dec 05 '09 at 00:18
  • @John Saunders: Interesting point. I was only trying to break out "pieces" in an attempt to create a "better" display. When I use built-in web clients to test the service, the return of msg.ToString() just results in a big stream of XML (i.e. no nice formating). Your point provides another justification to simplify the thing to just ex.ToString() and forget about trying to "break" with newline(s) because it doesn't work anyway. Thanks. – John Adams Dec 08 '09 at 20:29

1 Answers1

1

You can have line numbrers in Stack Trace messages but you need to include .PDB files. No problems even in release mode.

Dariusz
  • 12,358
  • 6
  • 46
  • 66
  • @Dario: I want to make sure I understand you on this. Because I publish only files needed to run the app, there is no source code published to the production webserver. But if I push out a .PDB file along with the corresponding .DLL, then when I request a Stack Trace it will show the line number(s) in files on my development machine (that is, the machine from which I initiated the PUBLISH operation). So a System Admin seeing this sort of file ref on a production machine should not freak out because there is no such user in c:\Documents and Settings on the web server. Do I have this correctly? – John Adams Dec 08 '09 at 20:22
  • Yes, PDB files contains information about user who publihed application (in other words: who compile and make .dll and coresponding .pdb files). – Dariusz Jan 12 '10 at 12:38