I\'ve got a VB.net application. Currently the release version of the application is produced without a PDB file. This gives me error logs lacking useful details such as line
I know I'm going to get beat up for this but...
I agree with Dave Markle, but I'd like to add that an advantage of publishing the PDB files is, as you said, VERY nice for debugging.
That said, I don't sell software, and the code I write is all for internal use in our company. In this context, I don't see an issue with putting debug code into production, along with the PDB files. I've never seen a performance hit, and in all honesty, our users rarely give us the right information if they encounter unhandled exceptions. Of course, we try to handle exceptions correctly, but as you know, errors will happen. Our strategy is to add a global exception handler to ALL projects, and log those events tot he database. These errors contain the line numbers because we do include the debug files, and as a result, we are able to quickly identify and react to bad code, fix it, and get more bug-free applications. To me (and to our users) this is a HUGE benefit that I wouldn't want to do without.
So if you're in a similar situation, I say forget the official stance (in this one case) and go ahead and publish the pdb files with ONE important caveat.
Be darn sure that any web application you deploy with the PDB files, be completely sure that ALL exceptions are handled properly, and you're not inadvertently exposing lines of code in a standard Asp.NET error page.