none
Сервер символов и сервер-источник (нужна подробная "человеческая" информация) RRS feed

  • Вопрос

  • Доброго времени суток.

    Где можно почитать подробную, понятную информацию на тему "Сервер символов"? В MSDN нашёл лишь это. По указанной ссылке нет никаких разъяснений на тему того, что такое "Сервер символов" и почему он называется именно так, а так же отсутствует подробная информация на эту тему, с поясняющими примерами, замечаниями и т.п. (о его создании/настройке/использовании). То, что имеется в наличии - сгенерировано роботом для роботов. Хотелось бы более подробной информации на эту тему, причём желательно на русском. В книге Джона Роббинса тема затронута в таком виде, как будто эта тема всем известна и очевидна, в следствии чего не нуждается в пояснении. 

    Аналогичные вопросы по серверу-источнику (вычитал у того же Джона Роббинса)... Я надеюсь, что на форуме есть те, кто разбирается в обозначенных темах, т.к. опросив не один десяток программистов я убедился в том, что найти того, кто хотя бы слышал, что это такое - очень сложно... :(((

    С уважением Андрей








    7 июня 2012 г. 16:54

Ответы

  • Насколько подробная информация вам нужна?

    Если на пальцах - то "сервер символов" - это сервер, позволяющий для данной dll/exe получить pdb-файл. Используется для того, чтобы не таскать везде вместе с dll/exe эти pdb-файлы (они достаточно много занимают, да и обычно в них содержится  информация не для внешнего использования). Т.е. сценарий использования такой:

    1. у клиента что-то совсем упало. вы залезли к нему на машину, сняли дамп процесса.
    2. принесли дамп на машину разработчика, открыли в отладчике.
    3. отладчик вытянул с "сервера символов" именно те pdb, которые соответствуют exe/dll у заказчика.
    4. вы спокойно отладили дамп

    сервер источник (скорее всего "сервер исходников") - это следующий шаг в упрощении production debugging. на самом деле это обычный сорсконтроль - vss/svn/tfs.

    Дело в том, что в pdb-файлах хранится полная информация о том, какая именно строчка исходников соответствует какой именно инструкции в dll/exe. И на шаге 4 вы, теоретически, можете не просто смотреть на бинарный код. Вы можете видеть точный исходник, как если бы вы поймали исключение при локальной отладке в студии.

    Но в pdb-файлы компилятор вшивает только информацию о локальных путях. Например, там есть информация что байт 53544 в коде - это строка 33 в d:\projects\myproject\main.cs. Что не очень полезно, если у вас нет точной копии исходников, из которой собирался билд 2 месяца назад, лежащей в той же папке.

    Поэтому перед заливкой pdb в сервер символов на pdb натравливается спецутилита (про нее и расписано у Роббинса, как про сервер источников). Она вписывает в pdb инфу типа "содержимое d:\projects\myproject\ можно получить из svn, http://myserver/repos/myproject, ревизия 45, консольная команда svn up http://myserver/repos/myproject -r 45".

    Отладчик в (4) эту инфу читает, выполняет команду, и показывает вам нужный файл нужной ревизии, полученный из source server.

    PS Поздно, извините если получилось несколько запутанно.


    • Предложено в качестве ответа LXGDARK 8 июня 2012 г. 2:40
    • Помечено в качестве ответа Abolmasov Dmitry 14 июня 2012 г. 13:44
    7 июня 2012 г. 20:04
    Модератор
  • Извините, увлекся флеймом, ответил не на тот пост. Постараюсь прекратить флеймить.

    все утилиты, которые используются Роббинсом для работы с символами и исходниками, идут в составе Debugging Tools for Windows, в Windows SDK.

    • Помечено в качестве ответа Abolmasov Dmitry 14 июня 2012 г. 13:44
    8 июня 2012 г. 13:16
    Модератор

Все ответы

  • Андрей, пока мы не бросились перерывать весь интернет, а какая у вас стоит цель? Или, иными словами, какую полезность для себя вы хотите получить? Может есть более другие способы решения вашей задачи...

    7 июня 2012 г. 18:42
    Отвечающий
  • Андрей, пока мы не бросились перерывать весь интернет, а какая у вас стоит цель? Или, иными словами, какую полезность для себя вы хотите получить? Может есть более другие способы решения вашей задачи...

    Цель: разобраться в теме отладки приложений, используя в полном объёме те возможности, которые заложены в MS Visual Studio. Отладка не ограничивается умением расставлять брэйкпоинты и написанием модульных тестов.
    7 июня 2012 г. 18:48
  • Видити ли, по той ссылке, что вы кинули, идет описание как используются PDB файлы, которые просто хранят ваш код на C# (VB), чтобы VS в процессе "расстановки брэкпоинтов", показывала вам не IL код, а вашу программу. Что вы хотите из этого выжать, не очень понятно. Если вам скучно, и хочется почитать интересненького про отладку, то посмотрите на IntellyTrace в рабочей среде, про нагрузочное тестирование, про создание раскадровок и отчетов от клиентов. Я могу ошибаться, но это весьма полезнее, чем разобраться в том, что хранится в PDB.

    P.s. Может завтра с утра, когда проснуться более опытные коллеги, они вам расскажут что то другое... Подождите.

    7 июня 2012 г. 19:20
    Отвечающий
  • Что вы хотите из этого выжать, не очень понятно.

    Откройте книгу Джона Роббинса "Отладка приложений для Microsoft .NET" стр.94-107 и вы поймёте о чём я спрашиваю.

    Если вам скучно, и хочется почитать интересненького про отладку, то посмотрите на IntellyTrace в рабочей среде, про нагрузочное тестирование, про создание раскадровок и отчетов от клиентов. 

    Если мне будет скучно - я найду чем мне заняться.

    Может завтра с утра, когда проснуться более опытные коллеги, они вам расскажут что то другое... Подождите.

    Давайте будем либо писать по теме топика, либо ничего не будем писать. Если бы мне потребовалось "что-то другое" я бы об этом спросил.


    7 июня 2012 г. 19:40
  • Насколько подробная информация вам нужна?

    Если на пальцах - то "сервер символов" - это сервер, позволяющий для данной dll/exe получить pdb-файл. Используется для того, чтобы не таскать везде вместе с dll/exe эти pdb-файлы (они достаточно много занимают, да и обычно в них содержится  информация не для внешнего использования). Т.е. сценарий использования такой:

    1. у клиента что-то совсем упало. вы залезли к нему на машину, сняли дамп процесса.
    2. принесли дамп на машину разработчика, открыли в отладчике.
    3. отладчик вытянул с "сервера символов" именно те pdb, которые соответствуют exe/dll у заказчика.
    4. вы спокойно отладили дамп

    сервер источник (скорее всего "сервер исходников") - это следующий шаг в упрощении production debugging. на самом деле это обычный сорсконтроль - vss/svn/tfs.

    Дело в том, что в pdb-файлах хранится полная информация о том, какая именно строчка исходников соответствует какой именно инструкции в dll/exe. И на шаге 4 вы, теоретически, можете не просто смотреть на бинарный код. Вы можете видеть точный исходник, как если бы вы поймали исключение при локальной отладке в студии.

    Но в pdb-файлы компилятор вшивает только информацию о локальных путях. Например, там есть информация что байт 53544 в коде - это строка 33 в d:\projects\myproject\main.cs. Что не очень полезно, если у вас нет точной копии исходников, из которой собирался билд 2 месяца назад, лежащей в той же папке.

    Поэтому перед заливкой pdb в сервер символов на pdb натравливается спецутилита (про нее и расписано у Роббинса, как про сервер источников). Она вписывает в pdb инфу типа "содержимое d:\projects\myproject\ можно получить из svn, http://myserver/repos/myproject, ревизия 45, консольная команда svn up http://myserver/repos/myproject -r 45".

    Отладчик в (4) эту инфу читает, выполняет команду, и показывает вам нужный файл нужной ревизии, полученный из source server.

    PS Поздно, извините если получилось несколько запутанно.


    • Предложено в качестве ответа LXGDARK 8 июня 2012 г. 2:40
    • Помечено в качестве ответа Abolmasov Dmitry 14 июня 2012 г. 13:44
    7 июня 2012 г. 20:04
    Модератор
  • Вы обращаетесь за помощью и в ответ на полученную помощь начинаете грубить, а между тем книга 2004 года у на указанных вами страницах куча устаревшего бла бла бла, тогда как Алексей посоветовал изучать актуальные материалы и сделал вполне логичный вывод - если человек интересуется чем-то что 5 лет как не актуально, то ему скучно и хочется что то по изучать.

    Но что бы не прослыть простым подпевалой отвечу на ваш вопрос - сервер символов это местонахождения файлов (называемых "символами") со специальным содержимым, которые позволяют производить отладку в системных dll и dll сторонних производителей. Например вы вызываете WinApi и она выдает ошибку, которую вы не можете отладить. Что бы получить такую возможность вам нужeн "символы" для dll из которой вызван этот api. Хотя все это поддерживается и в VS2010 этот способ отладки практически не применяется потому что устарел. Практически все современные dll поддерживают более продвинутые способы отладки, которые вам кстати и предложили изучить.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    7 июня 2012 г. 20:14
  • LXGDARK, вы немного заблуждаетесь.

    Символы (отладочные символы, pdb-файлы) нужны не только для отладки системных/сторонних dll, но и для отладки вашего же кода. Просто для вашего кода их генерирует компилятор, и заботливо складывает в папку рядом с exe. А отладчик в первую очередь ищет символы в папке с exe.

    На отладочные символы (pdb) завязан вообще любой процесс отладки. Когда вы нажимаете F5 в студии, и отлаживаете свой код - но это происходит только потому, что студия находит сгенерированные компилятором pdb-ки. Без символов не будет никакой пошаговой отладки, никакого intellitrace, вообще никаких "более продвинутых способов". По простой причине - символы - это единственное, что связывает бинарник с исходным кодом. Вы применяете тот самый "устаревший способ отладки" десятки раз в день. И если вам надо отладить свою программу, для которой почему-то не сохранились pdb (например, потому что вы не знали что они вообще нужны) - то вам очень неповезло.

    Поэтому все или тягают pdb вместе с софтом ( при развертывании на своих серверах это вполне нормальный вариант), или складывают pdb на свой собственный сервер символов.  И индексируют их, чтобы потом не тратить время на поиск исходников. Или просто не заморачиваются, и отвечают "на моей машине работает" :).

    Роббинс - до сих пор самая актуальная книга по отладке. Сам факт ее прочтения дает +100000 к уровню отладки. Знание про .prefer_dml 1 дает оставшиеся +500 :)  Да, там нет ничего про intellitrace, но там есть то, что нужно, чтобы intellitrace вообще заработал где-то, кроме машины разработчика.

    7 июня 2012 г. 21:21
    Модератор
  • LXGDARK, вы немного заблуждаетесь.

    Спасибо за разъяснения и хотя я на самом деле слегка заблуждался в целом моя мысль была в том, что современному разработчику уж оооочень редко нужно вникать в закулисные способы отладки, если у него есть для этого специальные инструменты. Плюс если верить MSDN символы это .dbg - ныне не актуальный формат, а вот упомянутый вами .pdb везде именуется базой данных программы - более новый способ хранения отладочной информации. Везде на MSDN при упоминании серверов символов говорится о .dbg. Я не пытаюсь цепляться за термины, просто мой ответ исходил из прочитанной информации.

    Что до книги, то возможно она действительно имеет вес для узкого круга специалистов, но MS я полагаю постоянно совершенствует свои технологии (в частности и intellitrace), что бы такие книги приходилась читать не всем поголовно разработчикам, а только тем кому это уж действительно нужно. Плюс как мне кажется упомянутые вами +100000 нужны только тем кто занимается разработкой продуктов отладки, а не их использованием. Да и снова возвращаюсь к тому факту, что на MSDN в ветке об отладке не уделяется большого внимания значению закулисного способа работы отладки, подразумевая, что большинству это не нужно.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    • Изменено LXGDARK 8 июня 2012 г. 2:53
  • Поэтому все или тягают pdb вместе с софтом ( при развертывании на своих серверах это вполне нормальный вариант), или складывают pdb на свой собственный сервер символов.  И индексируют их, чтобы потом не тратить время на поиск исходников. Или просто не заморачиваются, и отвечают "на моей машине работает" :).

    Можно еще пару не компетентных вопросов?
    1. Если у меня нет исходников, то чем мне поможет наличие PDB файлов не очень понятно, т.к. да, ошибка воспроизвелась, исправить все равно нельзя.

    2. Действительно есть компании (команды, отдельные разработчики), которые поднимают "серевер символов" и при этом не использую TFS с бранчиванием релизного кода в отдельные ветки?

    Я еще раз пытаюсь понять, какую пользу мне может дать "сервер символов", если у меня весь код в TFS, все строиться им же, релизные ветки бранчуются и для них всегда есть актуальная версия исходников, а на рабочих серверах можно воспользоваться инструментарием пропогандируемым по первой из приведенных мной чуть выше ссылок? Буду признателен за развернутый ответ, т.к. может это действительно полезно, а мы не используем. Заранее спасибо. 

    Отвечающий
  • Благодарю за ответы.

    Если на пальцах - то "сервер символов" - это сервер, позволяющий для данной dll/exe получить pdb-файл.

    Насколько я помню из прочитанного - это не сервер, как таковой, а набор данных, хранящихся в виде определённой, достаточно простой структуры каталогов и файлов.

    вы залезли к нему на машину, сняли дамп процесса. принесли дамп на машину разработчика, открыли в отладчике.

    К сожалению, этого я пока не умею. Надеюсь, что далее в указанной мною книге эта тема подробно изложена.

    PS Поздно, извините если получилось несколько запутанно.

    Вовсе нет - всё изложено достаточно понятно. Вы пояснили мне некоторые моменты, которые я не понял в книге, спасибо.

    По обозначенной мною книге я нигде не могу найти исходников, на которые автор постоянно ссылается. Я искал и по названию книги, и по ISBN. В блоге автора читал информацию о том, что исходники обновлялись, но о том, где эти самые исходники находятся - информации не нашёл. Писал автору на почту, задавая вопрос на эту тему - ответа не последовало. Может быть вы знаете, где можно скачать их?

    Глава 2 обозначенной книги вообще читается сложно. Например, я создал каталоги серверных символов, внёс необходимые изменения в PATH, выполнил настройку каталогов поиска символов в настройках MS VS 2012, но... Далее автор пишет, что для того, чтобы созданные мною каталоги заполнить содержимым, следует воспользоваться написанным им скриптом. В коде этого скрипта демонстрируется, как правильно пользоваться утилитами Symchk.exe и Symstore.exe. Однако, поскольку исходников нет - соответственно нет и скрипта. Обозначенные утилиты имеют множество ключей, так что придётся потратить некоторое время на разбирательство о том, как мне всё таки наполнить созданные каталоги файлами символьной информации. Если можете разъяснить эту тему - буду весьма признателен.

    Возвращаясь немного назад вспоминаю, что автор расписывает то, какие он создал классные правила для Code Analysis и что ими можно воспользоваться, т.к. они находятся в исходниках книги... В общем - те же грабли.

    Роббинс - до сих пор самая актуальная книга по отладке.

    Да, я в курсе и спорить с очевидным фактом не собираюсь. Любой программист должен владеть той информацией, которая изложена в этой книге, дабы уметь грамотно выполнять отладку - именно по этой причине и читаю её.

  • Если у меня нет исходников, то чем мне поможет наличие PDB файлов не очень понятно, т.к. да, ошибка воспроизвелась, исправить все равно нельзя.

    Но ваши-то исходники у вас есть. Благодаря PDB, как я понял, вы сможете узнать, где именно ошибка. Если в вашем коде, то сами её и исправите, а если в чужом, исходников которых у вас нет (но есть PDB), то вы сообщите об этой ошибке их автору и он сам её исправит.

    Я еще раз пытаюсь понять, какую пользу мне может дать "сервер символов", если у меня весь код в TFS, все строиться им же, релизные ветки бранчуются и для них всегда есть актуальная версия исходников, а на рабочих серверах можно воспользоваться инструментарием пропогандируемым по первой из приведенных мной чуть выше ссылок? Буду признателен за развернутый ответ, т.к. может это действительно полезно, а мы не используем. Заранее спасибо. 

    Насколько я понял, сервер символов нужен в том числе и для того, чтобы можно было пошагово перемещаться не только в своём коде, но и в коде сторонних разработчиков, используемом в теле нашего кода. Поскольку время от времени мы вызываем функции Win API или функции др. библиотек, то наличие символов, предоставленных компанией Майкрософт, позволяют нам "проваливаться" в их код и продолжать пошаговую отладку, отслеживая ход выполнения программы, вместо того, чтобы перепрыгивать фрагмент кода, в котором что-то вызывается извне. Если ошибаюсь - прошу меня поправить.
  • Насколько я понял, сервер символов нужен в том числе и для того, чтобы можно было пошагово перемещаться не только в своём коде, но и в коде сторонних разработчиков, используемом в теле нашего кода. Поскольку время от времени мы вызываем функции Win API или функции др. библиотек, то наличие символов, предоставленных компанией Майкрософт, позволяют нам "проваливаться" в их код и продолжать пошаговую отладку, отслеживая ход выполнения программы, вместо того, чтобы перепрыгивать фрагмент кода, в котором что-то вызывается извне. Если ошибаюсь - прошу меня поправить.
    Ну пока в этом я вижу единственную сферу полезного применения сервера символов (именно .dbg). А вот применение базы данных приложения (.pdb) куда более очевидно, но все же знания аспектов работы с ними нужны не всем, поэтому с утверждением "Любой программист должен владеть той информацией, которая изложена в этой книге" я не соглашусь. Это должен, а точнее обязан знать программист-специалист по отладке, а вот любой должен уметь пользоваться отладкой в целом, а нее узкими тонкостями. Замечательно что вы начали понимать вопрос и хотите до конца в нем разобраться и еще лучше если будет момент, когда вам эти знания пригодятся, но я, те 10 программистов у которых вы спросили и Алексей Лосев скорее всего обратятся к этой информации, когда будет острая необходимость, а пока вполне справляемся без нее.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    • Изменено LXGDARK 8 июня 2012 г. 5:42
  • Вполне компетентные запросы, и процесс сборки у вас, судя по всему, отлично поставлен.

    Вы деплоите отладочные символы (pdb) на рабочие сервера. Поэтому у вас работают инструменты типа intellitrace. И поэтому вы можете отладить прямо на рабочих серверах. Или в крайнем случае - снять дамп, и отладить его на девелоперcкой машине, вручную стянув с рабочего сервера или из папки билдов и бинарники, и символы, и вручную забрав из tfs нужный changeset.

    Но не всегда можно выложить pdb как часть приложения. Например, десктопные приложения обычно поставляются без pdb.

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

    Сервер исходников - это не отдельный сервер. Практически, это и есть TFS + прогонка pdb через специальную утилиту, которая вписывает в pdb информацию о конкретном changeset-е, из которого был собран билд. Т.е. при отладке бинарников с такими "проиндексированными" символами вам не придется вручную забирать нужную версию из-под TFS. Отладчик сам вытянет из TFS и покажет вам нужную версию файла.

    Конкретно в TFS 2010 за работу с символами отвечает секция Basic/Source and Symbol Server Settings в стандартном build process template. Там всего два параметра:

    1. Index Sources. Это индексация pdb и вшивание в них информации о сервере исходников - имени вашего tfs host и номера changeset-а. Она включена по умолчанию, т.е. то, что у Роббинса расписано в главе про source server у вас скорее всего работает "из коробки", и при отладке развернутого приложения/дампа дебаггер сможет вытянуть вам соответствующие исходники. 

    2. Path to Publish Symbols - это путь к папке ("серверу символов"), в которую при билде надо складывать символы. На случай, если вы не деплоите их на production. Или на случай, если придется отлаживать дамп/запись intellitrace  на девелоперской машине - тогда вам не нужно будет вытягивать pdb-ки этого билда с продакшена/папки с билдами. И даже не придется вписывать пусть к папке билда в свойствах студии - сетевая папка с символами одна для всех билдов. TFS даже умеет удалять из нее символы при удалении билда из TFS.

    PDB - это не замена исходников. Это связь между исходниками и бинарниками. Если у вас есть pdb, но нет исходников - плохо, потому что вы не сможете ничего исправить. Но вы хотя бы сможете отладить и посмотреть на значения локальных переменных, на нормальный стектрейс со всеми параметрами, походить по объектам. И сможете снять дамп и прислать его тому, у кого есть исходники. 

    Если у вас есть исходники, но нет pdb, и есть ошибка, которая воспроизводится только на рабочем сервере, или на тестовой машине - тоже плохо. Т.к. отладить вы нормально не сможете, записать что-то вроде intellitrace - тоже. На самом деле первое, что вы сделаете - это соберете билд (с pdb) на своей машине, пытаясь воспроизвести проблему. А потом, попытавшись записать intellitrace, зальете этот билд на рабочий сервер. Сервер символов просто убирает лишние телодвижения на пути к состоянию "есть и исходники, и символы".

    Нет смысла хранить старые отладочные символы, если единственный применяемый способ отладки - воспроизвести баг под студией на девелоперской машине, на свежесобранных из исходников бинарниках и отладочных символах.

    Но они нужны при любом способе отладки, подразумевающем запуск отладчика на уже готовых бинарниках - например, при использовании intellitrace на сервере (по вашей ссылке выше), при анализе дампов, при реальной живой отладке на рабочих серверах, даже при удаленной отладке отладке тестового окружения студией.

    8 июня 2012 г. 11:17
    Модератор
  • Но они нужны при любом способе отладки, подразумевающем запуск отладчика на уже готовых бинарниках - например, при использовании intellitrace на сервере (по вашей ссылке выше), при анализе дампов, при реальной живой отладке на рабочих серверах, даже при удаленной отладке отладке тестового окружения студией.


    Спасибо за разъяснения.
    8 июня 2012 г. 11:41
    Отвечающий
  • LXGDARK, проблема скорее не в том, что те 10 программистов обратятся к информации когда будет острая необходимость. А в том, что все 10 не будут вообще знать про возможность отладки на живом сервере без студии. Или не будут понимать, что нельзя выбрасывать pdb (а они занимают место). И, попытавшись использовать intellitrace, увидят жизнерадостное "Symbols not found".

    Да и определение "отладки в целом" очень размыто. Человек умеет только запускать по F5, ставить брекпойнты по F9, идти по коду по F10/F11, и смотреть значения мышкой. Он владеет отладкой в целом? Ну тогда мой пятилетний сын умеет ездить на машине - он же жмет на педали и крутит руль.

    Агрументация "надо будет - обратимся к информации" немного дырява. Не осознавая возможностей от дополнительных знаний, вы никогда не попытаетесь их получить. Подход "сильно прижмет - узнаю и выучу" еще кое-как можно допустить для студента/джуниора. Но уж никак не от полноценного разработчика. 

    В целом книга Роббинса посвящена не столько символам, сколько приемам вполне повседневной отладки в Visual Studio - визуализаторам отладки, фичам типа "make object id" (знание про него - это практически быстрый тест на уровень разработчика ;), использованию >immed, использованию ассертов/трассировки.

    Конкретный примеры из жизни про "отладку в целом", раз пошел такой флейм:

    1. У меня тут есть проект, деревообработка, выпиливание деталей на листах. Так вот, девелопер, который на нем сидел пару лет назад, умел пользоваться отладкой "в целом". И дебагая код, который активно работал с фигурами в виде точке/векторов, он поступал как вполне обычный разработчик - смотрел в отладке значения x/y для каждой точки фигуры и вырисовывал фигуру на листе миллиметровой бумаги. Точек так по 90 на фигуру. У него была очень острая необходимость в визуализаторах отладки, но он про них так и не узнал. Вы про них знаете?

    2. Еще один проект, веб-приложение. Для тестеров деплоится на соседний сервер в локалке (как у всех). При ошибках с "непонятным" стектрейсом все стягивали старую версию исходников, собирали, цеплялись к базе, и пытались воспроизвести ошибку локально. Это час-два совершенно дурной работы. Сейчас на тестовом хостинге висит студийный сервис ремоут дебага, и можно за полминуты увидеть ту же ошибку уже под отладчиком без всех этих "пересобрать/перезалить/перезапустить".

    3. Вчера я поймал совершенно непонятную ошибку типа UnauthorizedAccessException с обрезанным стектрейсом на продакшене (в Канаде). У меня ушло минут 5 на виндебаг, и проблема оказалась не в коде, а в мелкой разнице в настройках. Без нормального знания отладки ушло бы 2-3-10 часов на допихивание дополнительного логгирования, как сделал бы "владеющий отладкой в целом".

    8 июня 2012 г. 12:13
    Модератор
  • >> Насколько я понял, сервер символов нужен в том числе и для того, чтобы можно было пошагово перемещаться не только в своём коде

    Сервер символов (точнее, сами символы) нужны чтобы отладить вообще любой код. Сервер, про который рассказано у Роббинса - это просто способ аккуратно хранить ваши отладочные символы для вашего же кода, для всех билдов, в одном месте. Насколько я понял, сервер символов нужен в том числе и для того, чтобы можно было пошагово перемещаться не только в своём коде Если у вас не будет символов для своего кода (например, при отладке на живом сервере), то вы точно так же не сможете идти в нем по шагам.

    Вообще понятие "свой код" существует только на машине разработчика, и означает что-то вроде "тот код, который открыт в данном экземпляре студии". Как только бинарники начинают работать не под студией - разница между чужим и своим кодом исчезает, он весь становится "чужим".


    8 июня 2012 г. 12:22
    Модератор
  • Надеюсь, что вы не оставите без внимания вопросы, обозначенные мною выше. :)

    8 июня 2012 г. 12:24
  • PashaPash вы в самую малость не верно меня поняли. Используя ваш пример с авто я перефразирую так - что бы называться водителем не нужно уметь делать ее полный ремонт, типа того что делают в серверных центрах. Да умение делать такой ремонт безусловный плюс но уж ни как ни неотъемлемая часть звания "Водитель".

    То же самое и с разработкой - в моих проектах не выполняются мега задачи и у меня нет мега заказчиков, но хлеб я свой зарабатываю и конечно же могу потратить кучу времени на изучение премудростей отладки, но это время в моей текущей ситуации не окупится. А вот наступит другая ситуация - я вспомню что был этот пост, перечитаю его, почитаю в довесок нужную литературу и буду уметь это делать. Ведь вы же не ставили себе барьер типа - пока не изучу все тонкости отладки не напишу ни одного проекта, все что вы нам расписали это опыт, который приходит не сразу.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    8 июня 2012 г. 12:55
  • 1. Вроде ответил - ради этого и тянут pdb на живой сервер или на сервер символов, чтобы иметь возможность хоть как-то отладить. Многие деплоят pdb на живой сервер, ради получения имен файлов и строк в сообщениях об ошибках (может быть и ваша команда тоже). Ситуация "я на сервере, вижу невоспроизводимую на девелопеской машине ошибку, есть pdb, но на сервере нет исходников" лучше чем вариант "и pdb для этой версии бинарников нет". Потому что вы можете снять дамп и притянуть его+символы туда, где исходники есть. Или отправить его тому, у кого есть исходники, в надежде что там есть люди, владеющие отладкой :)

    2. Сервер символов вообще никак не влияет на наличие сорсконтроля или на стратегию бранчевания. Скорее всего да, есть, есть - все команды можно поделить на использующие/не использующие сервер символов. все команды можно поделить на использующие tfs/не использующие tfs. Два измерения, ровно 4 категории разработчиков.

    Есть те, кто использует и сервер символов и tfs (т.к. сам по себе процесс сборки билдов в tfs очень сильно подталкивает разработчиков к использованию сервера символов, там все готово и проинтегрировано). Есть те, кто использует сервер символов, но используют другой сорсконтроль. Одно другому не мешает, скорее наоборот. Представить тех, кто использует сервер символов, но не использует сорсконтроль вообще сложно. Но только потому что необходимость в сорсконтроле появляется чаще и раньше, а не потому что сорсконтроль как-то "заменяет" отладочные символы.

    8 июня 2012 г. 13:04
    Модератор
  • 1. Вроде ответил

    Там ещё было это:

    ...

    Я искал и по названию книги, и по ISBN. В блоге автора читал информацию о том, что исходники обновлялись, но о том, где эти самые исходники находятся - информации не нашёл. Писал автору на почту, задавая вопрос на эту тему - ответа не последовало. Может быть вы знаете, где можно скачать их?

    ...

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

    8 июня 2012 г. 13:10
  • PashaPash вы в самую малость не верно меня поняли. Используя ваш пример с авто я перефразирую так - что бы называться водителем не нужно уметь делать ее полный ремонт, типа того что делают в серверных центрах. Да умение делать такой ремонт безусловный плюс но уж ни как ни неотъемлемая часть звания "Водитель".

    Так вся заморочка в том, что нет там никаких премудростей. Не обязательно уметь отлаживать дампы. Тот инструмент, которым вы каждый день пользуетесь - отладчик студии - умеет кучу всего, что реально облегчает повседневную отладку. На самых обычных проектах, с минимальным вложением времени на изучение возможностей отладчика. [дырявая абстракция]Базовый уровень, которым владеет дефолтный девелопер - это езда на 1-й передаче. Иногда стоит включить 2-ю[/дырявая абстракция]
    8 июня 2012 г. 13:12
    Модератор
  • Извините, увлекся флеймом, ответил не на тот пост. Постараюсь прекратить флеймить.

    все утилиты, которые используются Роббинсом для работы с символами и исходниками, идут в составе Debugging Tools for Windows, в Windows SDK.

    • Помечено в качестве ответа Abolmasov Dmitry 14 июня 2012 г. 13:44
    8 июня 2012 г. 13:16
    Модератор