views:

821

answers:

3

I am deploying ASP.NET and Web Service solutions to IIS for a development server. It looks like the last person that did this job deployed all the .pdb files too. I asked about it, and was told that they "provide better stack trace info in the logs" if they are left on the server.

Is there any truth to this? I've always left them behind, never deploying them to anywhere other than my local machine.

For an internal development IIS server (not production, not accessible to the outside world) is there any reason to or not to deploy the .pdb files? Is there anything bad that could happen? Do they really provide any benefit?

+12  A: 

If you are logging exceptions, then deploying the PDB files ensures that the exceptions include line numbers (so Steven A. Lowe has informed me on many occasions ;) )

Andrew Rollings
So what does building an aplication in Release vs Debug do? anything? I'm used to the Java world where compiling debug inserts line#s and other debug info directly into the .class files.
rally25rs
Link here: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/4de6861f-e723-4def-bcaf-aa717a3e1897/Summary in Debug: No optimizations, [Debuggable] attribute added, PDB's deployed, #IF DEBUG conditionally compiled included, #IF RELEASE code not included.
Andrew Rollings
+1 for spelling my name right ;-)
Steven A. Lowe
+5  A: 

deploying .pdb files is helpful if you wish to remotely debug your application.

there is an MSDN article here explaining the process

Dav Evans
+8  A: 

I always figured the .pdb files were only used by the debugger. If the runtime always checks for them for debug info, that should mean slower execution when throwing an exception, because it has to read the .pdb, right?

So I made a quick test:

using System;
using System.Text;

namespace PdbSpeedTest
{
    class Program
    {
     static void Main(string[] args)
     {
      DateTime start = DateTime.Now;
      try
      {
       Program p = new Program();
       p.Looper(0);
      }
      catch (NotImplementedException e)
      {
       Console.WriteLine(e.StackTrace);
      }
      TimeSpan span = DateTime.Now - start;
      Console.WriteLine(span.TotalMilliseconds.ToString());
     }

     internal void Looper(int x)
     {
      try
      {
       if (x < 100)
        Looper(x + 1);
       else
        throw new NotImplementedException("blah!");
      }
      catch (NotImplementedException e)
      {
       throw new NotImplementedException("blah!", e);
      }
     }
    }
}

This just recurses 100 levels deep and throws an exception. Now for the runtime results:

Running as a debug build with the .pdb in the same folder:

C:\Work\PdbSpeedTest\bin\Debug>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x) in C:\Work\PdbSpeedTest\Program.cs:line 37
   at PdbSpeedTest.Program.Main(String[] args) in C:\Work\PdbSpeedTest\Program.cs:line 16
31.2504

Running as a debug build without the .pdb:

C:\Work\PdbSpeedTest\bin\Debug>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x)
   at PdbSpeedTest.Program.Main(String[] args)
15.6252

Running as a release build with the .pdb:

C:\Work\PdbSpeedTest\bin\Release>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x) in C:\Work\PdbSpeedTest\Program.cs:line 37
   at PdbSpeedTest.Program.Main(String[] args) in C:\Work\PdbSpeedTest\Program.cs:line 16
31.2504

Running as a release build without the .pdb:

C:\Work\PdbSpeedTest\bin\Release>PdbSpeedTest.exe
   at PdbSpeedTest.Program.Looper(Int32 x)
   at PdbSpeedTest.Program.Main(String[] args)
15.6252

These were run from a regular old command prompt, not inside Visual Studio. So the .pdb definitely does add stack trace info, and slows down the exception handling. Very interesting!

rally25rs
Nice research :) +1
Andrew Rollings
really good to learn
erdogany