Развертывание файлов .PDB в IIS. Любая выгода?

Я внедряю решения ASP.NET и веб-служб в IIS дляразвитие сервер. Похоже, что последний, кто выполнил эту работу, тоже развернул все файлы .pdb. Я спросил об этом, и мне сказали, что они «предоставляют лучшую информацию трассировки стека в журналах», если они остаются на сервере.

Есть ли правда в этом? Я всегда оставляю их позади, никогда не размещаю их где-либо, кроме моей локальной машины.

Для внутреннего сервера разработки IIS (не производственного, недоступного для внешнего мира) есть ли причина для развертывания файлов .pdb или нет? Что-нибудь плохое может случиться? Они действительно дают какую-то выгоду?

Ответы на вопрос(3)

если вы хотите удаленно отлаживать приложение.

есть статья в MSDNВот объясняя процесс

Решение Вопроса

то развертывание файлов PDB гарантирует, что исключения содержат номера строк (поэтомуСтивен А. Лоу сообщал мне много раз;))

 Andrew Rollings19 дек. 2008 г., 19:20
Ссылка здесь:social.msdn.microsoft.com/Forums/en-US/clr/thread/...  Сводка в отладке: оптимизация отсутствует, атрибут [Debuggable] добавлен, PDB развернут, условно скомпилирована #IF DEBUG, код #IF RELEASE не включен.
 Steven A. Lowe20 дек. 2008 г., 07:16
+1 за правописание моего имени ;-)
 CodingWithSpike19 дек. 2008 г., 18:59
Так что же делает построение приложения в Release vs Debug? что-нибудь? Я привык к миру Java, где компиляция отладки вставляет строки # и другую отладочную информацию прямо в файлы .class.

что файлы .pdb использовались только отладчиком. Если среда выполнения всегда проверяет их на предмет отладочной информации, это должно означать более медленное выполнение при возникновении исключения, поскольку оно должно читать .pdb, верно?

Итак, я сделал быстрый тест:

using System;
using System.Text;

namespace Pd,bSpeedTest
{
    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);
            }
        }
    }
}

Это просто повторяет 100 уровней и создает исключение. Теперь для результатов выполнения:

Работает какотлаживать строитьс .pdb в той же папке:

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

Работает какотлаживать строитьбез .pdb:

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

Работает какрелиз строитьс .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

Работает какрелиз строитьбез .pdb:

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

Они запускались из обычной старой командной строки, а не из Visual Studio. Так что .pdb определенно добавляет информацию трассировки стека и замедляет обработку исключений. Очень интересно!

 Chris Marisic21 февр. 2014 г., 00:35
@JoshuaFrank Я не проводил никакого анализа, но из работы, подробно изложенной в этом ответе, я бы предположил, что во всех случаях возникает исключение.
 Kevin P. Rice06 сент. 2012 г., 06:20
@ChrisMarisic Да. Это недостаток. Есть обходной путь:support.microsoft.com/kb/312629
 Andrew Rollings21 дек. 2008 г., 22:46
Хорошее исследование :) +1
 Kevin P. Rice15 янв. 2012 г., 22:35
Наверное должно бытьподчеркнул это медленное выполнение происходит только с исключениями - в противном случае создается впечатление, что файлы .pdb снижают производительность даже при сборке релизов. Я не верю, что производительность ухудшается, если ваш код работает без исключений (именно поэтому вы не должны использовать код записи, который использует исключения для обычного управления ветвями).
 Joshua Frank19 февр. 2014 г., 19:45
@ChrisMarisic: вы говорите, что наличие файла pdb снижает производительность, когдаThreadAbortException являетсявыброшены, или только если у вас есть обработчик, который фактически запрашивает данные трассировки стека? Я обработал проблему Redirect / ThreadAbortException, просто проигнорировав это исключение в моем обработчике исключений, и поэтому я ожидал, что файл pdb не повлияет на производительность. Но так ли это?
 Chris Marisic05 сент. 2012 г., 23:43
@ KevinP.Rice, а затем у вас есть .NET Framework, который полностью игнорирует ее, когда речь идет об очень ключевом и часто используемом аспекте,Response.Redirect который бросаетThreadAbortException потому что .NET не поддерживает истинные сигналы.
 yusuf29 дек. 2008 г., 09:07
действительно хорошо учиться

Ваш ответ на вопрос