Профилирование производительности Visual Studio — не удалось найти символы библиотеки классов

Насколько я могу судить из вашего решения, инструментальная .dll находится в папке «obj» библиотеки классов.

Теперь это может быть просто я говорю, когда я должен держать рот на замке (потому что я мало разбираюсь в профилировщике Visual Studio, и я понятия не имею, почему/если кто-то захочет инструментировать двоичные файлы "obj", а не "bin") , и поэтому, я думаю, мне лучше описать ход моих мыслей:

VS ищет файлы символов (в частности, файл .instr.pdb) в расположении «Временные файлы ASP.NET», потому что именно оттуда он загрузил dll библиотеки классов. Однако он не найдет его, потому что этот файл создается в obj\Debug в проекте библиотеки классов и не копируется в папку «bin» веб-приложения, поэтому он никогда не копируется в «временные файлы ASP.NET». либо.

Удаление целей из Performance Explorer и выбор «Добавить цель проекта», проверка обоих проектов, дает мне именно то, что у вас (и у меня) было раньше:

• PerformanceTest.dll в проекте веб-приложения ...\bin\Debug
• SomeLibrary.dll в проекте библиотеки классов ...\obj\Debug

Так что, видимо, VS хочет, чтобы это было, работает это или нет. Он обрабатывает библиотеку классов в obj\Debug, а затем забывает о вновь сгенерированных символах при запуске профилировщика.

Но если вместо этого я снова удалю цель "SomeLibrary.dll", выберите "Добавить целевой двоичный файл..." и вручную выберите ее в веб-приложении ...\bin\Debug.. , И затем начните профилирование: отчет выглядит примерно так же, но я могу просмотреть «SomeLibrary», и я получаю это в выводе:

Preparing web server for profiling.
Profiling started.
Instrumenting E:\...\PerformanceTest\\bin\PerformanceTest.dll in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 11.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
   E:\...\PerformanceTest\bin\PerformanceTest.dll -->
   E:\...\PerformanceTest\bin\PerformanceTest.dll
Original file backed up to E:\...\PerformanceTest\bin\PerformanceTest.dll.orig
Successfully instrumented file E:\...\PerformanceTest\bin\PerformanceTest.dll.
Warning VSP2013: Instrumenting this image requires it to run as a 
32-bit process. The CLR header flags have been updated to reflect this.
Instrumenting E:\...\PerformanceTest\bin\SomeLibrary.dll in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 11.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
   E:\...\PerformanceTest\bin\SomeLibrary.dll --> 
   E:\...\PerformanceTest\bin\SomeLibrary.dll
Original file backed up to E:\...\PerformanceTest\bin\SomeLibrary.dll.orig
Successfully instrumented file E:\...\PerformanceTest\bin\SomeLibrary.dll.
Warning VSP2013: Instrumenting this image requires it to run as a 
32-bit process. The CLR header flags have been updated to reflect this.
Launching web server with profiling.
Launching profilable project.
Profiling process ID 14652 (iisexpress).
Process ID 14652 has exited.
Data written to E:\...\PerformanceTest\PerformanceTest_130810(1).vsp.
Profiling finished.
Loaded symbols for 
   C:\...\App_Web_yzwcgfbx.dll.
Loaded symbols for 
   C:\...\assembly\dl3\928eb82e\75dbb6f1_5695ce01\PerformanceTest.dll.
Loaded symbols for 
   C:\...\assembly\dl3\6c0d460d\5208c7f1_5695ce01\SomeLibrary.dll.
Profiling complete.

Это правильный способ исправить это? Опять же, я понятия не имею. Если нет, может быть способ заставить профилировщик искать символы в папке obj библиотеки классов, когда он не находит их там, где он ожидает, или способ копирования файла .instr.pdb в папку bin перед -profiling, чтобы он был включен в теневую копию временных файлов ASP.NET.

У меня была эта проблема в VS2014 с exe-файлом, который был создан для «любого процессора» с установленным «предпочитать 32-разрядный», тогда как в упомянутых библиотеках не было «предпочесть 32-разрядный» (т. е. 32-разрядный exe, 64-разрядные библиотеки) .

Изменение исполняемого файла, чтобы он не «предпочитал 32-битный», устранило проблему с символами, я думаю, это связано с тем, что библиотеки изменены, чтобы соответствовать разрядности исполняемого файла (во время инструментирования), и символы больше не совпадают.

Это решение сработало для меня:

http://www.brothersincode.com/post/Matching-symbols-could-not-be-found-Performance-Profiler.aspx

Вы также можете попробовать сделать это наоборот, то есть удалить свою dll как есть и попытаться поместить ее из корзины, потому что это может быть и наоборот.

Мне удалось профилировать мою библиотеку классов, но только из консольного приложения. Мне не удалось профилировать библиотеку классов во время сеанса профилирования производительности приложения ASP.NET.

Несколько разных ссылок, которые, увы, не решили мою проблему, но могут дать вам некоторые наводки:

• Запустите Developer Command Prompt for VS2012
• Затем вы можете использовать это, чтобы VSPerfReport <yourreport.vsp> /debugsympath выяснить, откуда должна быть загружена SomeLibrary.dll.
• Советы по устранению неполадок http://msdn.microsoft.com/en-us/library/bb385766.aspx

Принятый в настоящее время ответ помог мне добраться туда, но я постараюсь скромно дать немного более простые инструкции тем, кто пытается выполнить то же самое, что и я, на всякий случай, если я сэкономлю пару часов тяжелого гугления. для кого-то. Я безуспешно пытался профилировать службу WCF, которая использует внешние сборки, которые загружаются путем отражения во время выполнения, и эта служба должна запускаться моим пользовательским клиентом. У меня было 2 проблемы: моя служба WCF вообще не запускалась во время сеанса профилирования (но при отладке она всегда запускалась), а затем, когда по какой-то причине это происходило, Visual Studio не могла загружать символы для внешних сборок. Таким образом, чтобы обе вещи работали, мне нужно было создать сеанс производительности инструментовки с целью, установленной для моей основной службы WCF вместе с пользовательскими внешними сборками, и установить режим запуска - Internet Explorer (в противном случае служба не запустится). Никаких исполняемых файлов или указаний на клиента из решения. Тогда я не стал сразу запускать профилировщик, а изменил его свойства в окне "Performance Explorer" и добавил бинарник моего пользовательского клиента на вкладку "Запуск" для запуска вторым (сразу после самого сервиса). Это также помогло иметь правильную «Ссылку на службу» прямо в клиенте (на самом деле я ее не использую, я использую общую сборку и генерирую каналы с помощью ChannelFactory) и сначала запускать клиент в режиме отладки (но фактически никогда не обращаясь к службе ). Может быть, это неправильный способ сделать это, но это помогает, и я, наконец, могу профилировать свою службу после 2 дней гугления - не так много документов, доступных по этой теме, и принятый ответ на этот вопрос о стеке - лучший ресурс, который я найденный.

Я использую Visual Studio 2019 и сталкиваюсь с той же проблемой при инструментальном профилировании веб-сайта ASP.NET.

Сильно вдохновленный приведенным выше решением JimmiTh, я добавил пути [ProjectPath]/obj/Debug отсутствующего проекта в параметры VS. -> Отладка-> Символы. После повторного профилирования я мог легко получить доступ к исходному коду и получить более точную диагностику профилирования.