Ответ 1
Щелкните правой кнопкой мыши по решению → Свойства
Посмотрите в разделе Общие свойства → Проект запуска
Выберите несколько проектов запуска
выберите "Начать действие" для проектов, которые нужно отлаживать.
Хорошо, что у меня есть:
Visual Studio 2010 RC, W7 x64, запустил новый тип проекта приложения Silverlight. Хостинг приложения Silverlight в проекте веб-приложения ASP.NET. Silverlight версии 3.0. Добавлен класс LinqToSQL, служба WCF, приложение для тестирования Winform (проект в решении) и несколько классов (также как проекты в решении).
Вчера, внезапно, я получил "Точку останова в настоящий момент не будет. Для этого документа не были загружены никакие символы. ' сообщение появится в среде IDE, но оно влияет только на веб-приложение, я могу отлаживать Silverlight и приложение Winform.
Что я пытался/сделал, чтобы избавиться от сообщения:
Итак, это происходит во второй раз в моей жизни. в прошлый раз я решил это, удалив временную папку файлов ASP.NET, но на этот раз мне нужна ваша помощь.
Щелкните правой кнопкой мыши по решению → Свойства
Посмотрите в разделе Общие свойства → Проект запуска
Выберите несколько проектов запуска
выберите "Начать действие" для проектов, которые нужно отлаживать.
У меня была такая же проблема, и после googling я нашел два типичных решения для этого:
Убедитесь, что отладчик Silverlight активирован в проекте .Web. Откройте свойства проекта и выберите отладчик Silverlight на вкладке "Веб".
Перезапустите Visual Studio и удалите все папки bin и obj.
Но никто из них не работал у меня. Затем кто-то упомянул далеко вниз нить, чтобы вместо этого использовать IE в качестве браузера. Это заставило работать отладочные и контрольные точки!
Edit:
Позже я боролся с тем, что IE9 не работает, потому что он приписывает неправильный процесс. Вместо ручной привязки к правильному процессу IE каждый раз я нашел опрятный трюк:
Теперь Visual Studio запустит IE при запуске проекта .Web и подключится к правильному процессу. Это должно сделать это.
Всякий раз, когда у меня возникла эта конкретная ошибка, оказалось, что папка, из которой загружается сборка Visual Studio, отличается от папки, из которой выполняется веб-приложение.
То есть сервер приложений запускает приложение из
C:\dev\MyApplication\bin
но Visual studio отлаживается от
C:\dev\MyOtherApplication\bin (or something along those lines, anyway).
Примечание. По разным причинам я выполняю мою отладку с помощью IIS в качестве хоста приложения, а не для dinky автономной вещицы, которую используют большинство людей. Это может повлиять на полезность моего ответа!
Обновление
Для IIS каталог сервера приложений (т.е. C:\dev\MyApplication
выше) является физическим каталогом, настроенным для веб-приложения, - это можно контролировать, изменив основные настройки для приложения.
Для Visual studio каталог отладки (т.е. C:\dev\MyOtherApplication
выше) - это каталог, в котором находятся ваши файлы svc
, обычно тот же каталог, что и файл проекта csproj
.
Проблема для меня оказалась в том, что в конфигурации Debug включен флажок Properties- > Build- > Optimize. Отключилось, перестроено и отладка работала нормально.
Причина того, что вы столкнулись, заключается в том, что PDB ( "PDB" означает "База данных программ", запатентованный формат файла (разработанный Microsoft) для хранения отладочной информации о программе) несовременны, это может быть связано с по некоторым причинам:
1- Как сказал Беван, вы можете отлаживать другое приложение!
2- Вы отлаживаете другую версию того же приложения. Например, вы подключили ранее построенное приложение с текущей версией кода для отладки без (re) его создания.
Очистка или восстановление решения решает такие проблемы для меня.
Чтобы убедиться, что проблема не ваша, попробуйте отладить одно и то же приложение с VS 2008 (я боюсь, что это может быть ошибка в VS 2010 - она все еще бета!).
У меня была та же проблема, я отлаживал свой проект, и мне пришлось щелкнуть правой кнопкой мыши проект и выбрать "новый экземпляр отладки". Мне нужно было сделать это только один раз, после чего он работал нормально.
Эта ошибка возникает каждый раз для меня, и я всегда могу отследить ее обратно к настройкам проекта для соответствующей сборки. Вам не нужно "ждать", пока ваш код не будет соблюдать точку останова или пока вы не установите точку останова, чтобы знать, какие сборки имеют загруженные символы.
Когда вы запускаете проект в режиме отладки, он будет отображать в окне "Выход", в котором сборки имеют символы, загруженные, как показано ниже (вам может потребоваться открыть изображение на новой вкладке): T
Итак, в этом случае BASD.Core.Data.dll НЕ загружает символы. Таким образом, вы можете сравнить параметры проекта для этой сборки с данными другой сборки, которым удалось загрузить символы, чтобы понять, почему некоторые делают, а некоторые не загружают символы.
"Для меня", однако, "каждое" время это происходит из-за того, что информация Debug не создается. Поэтому я открываю Project Properties > Build > Advanced в проекте (С#).
Итак, для Basd.Core.Data.dll выше, т.е. никаких символов, для расширенных настроек сборки были:
В то время как для Basd.Core.Configuration.dll, то есть сборки, где я мог установить и нажать точку останова, были следующие настройки:
Итак, я выводил информацию об отладке в последнем проекте, а не в первую, поэтому моя способность ударить точку останова в файле Basd.Core.Configuration.dll
Также обратите внимание, что этого недостаточно, чтобы просто иметь файл .pdb в папке bin проекта для данной .dll, потому что он может быть устаревшим и поэтому не подхвачен Visual Studio как действительный файл символа для .dll, который вы пытаетесь выполнить.
Также обратите внимание, что изменение конфигураций сборки может изменить параметры информации о сборке и из которых извлекаются символы.
(я понимаю, что в этом случае я в режиме Release, но метод все еще применяется)
Перейти к Свойствам проекта → Сборка → Дополнительно...
В разделе "Выход" выберите "полный" в раскрывающемся меню "Отладка информации"
Убедитесь, что вы запускаете свою программу в режиме DEBUG, а не в режиме RELEASE.
Я только что решил эту проблему в соответствии с Развертыванием приложений Silverlight. (Этот ответ является дубликатом некоторых других, но я попытаюсь объяснить его более подробно.)
Вероятно, проблема в том, что приложение Silverlight не будет правильно размещено в вашем веб-приложении при сборке/запуске. Это проблема ссылок - она проста для понимания, но не очевидна в первый раз, когда вы столкнулись с ней.
Как и любая другая ссылка на проект, ссылка на проектную копию должна быть скопирована в папку с базой данных проекта для отладки. Для библиотек классов это происходит, когда вы щелкаете правой кнопкой мыши и выбираете "Добавить ссылку...". Для Silverlight вы должны добавить ссылку через Свойства проекта.
Это добавляет ссылку на приложение Silverlight из вашего веб-приложения для хостинга и гарантирует, что файл xap
будет скопирован в веб-приложение при сборке или развертывании. Это означает, что текущее приложение Silverlight и его файлы отладки находятся внутри отлаживаемого приложения, и вы сможете пройти через код.
У меня была такая же проблема в Windows 7 и пробовали все: очищенные библиотеки DLL, список исследуемых модулей, отключили "Just My Code" и т.д.
Проблема была решена после запуска Visual Studio "как администратора". Честно. Почему Microsoft не может просто предупредить меня, что он не работает "как администратор"? Это сэкономит мне несколько часов работы.
Если вы отлаживаете веб-проект, убедитесь, что в файле web.config установлен атрибут debug = "true":
<system.web>
<compilation debug="true" .../>
Была та же проблема
По какой-то причине одна из DLL была зарегистрирована в GAC, поэтому она всегда отличалась от кода.
Как только я удалил его из GAC, проблема была решена.
Отладка → Присоединить к процессу →
выберите Отладить следующие типы кода: →
выберите Управляемый v3.5, v3.0, v2.0 или Управляемый v4.5, v4.0
Для меня проблема заключалась в том, что я включил "Оптимизировать код" на вкладке "Сборка" моих настроек проекта.
Для тех, кто использует Visual Studio 2008, а не Visual Studio 2010 и получает эту ошибку. Ответы выше не помогли мне в этой ситуации, поэтому я делюсь своим опытом.
Если вы отлаживаете веб-приложение IIS в Visual Studio 2008, подключившись к процессу w3wp.exe, а не используя ASP.NET Development Server для отладки (начните с отладки), это может быть вашей проблемой:
Visual Studio может по-прежнему ссылаться на файл символа (файл, используемый во время отладки) из вашей DLL из процесса IIS, устаревшего. И этот файл символа был воссоздан перекомпиляцией исходного кода .NET, но процесс IIS по-прежнему ссылается на старый файл символов.
Чтобы исправить:
Просто прекратите отладку в Visual Studio, перезапустите веб-приложение и повторно присоединитесь к процессу. Затем точки останова должны перейти от желтого (когда вы увидите эту ошибку) к красному снова.
========================
Другие вещи, чтобы попробовать (нашли новую ситуацию сегодня):
Сделайте каждую пулю по ссылке ниже ONE AT TIME, но повторите шаги ниже с каждым, который вы попробуете.
1.) Остановить отладку (нажмите значок красного квадрата) в Visual Studio
2.) Чистое решение
3.) Build Solution
4.) [ИНСТРУКЦИЯ ПО ИНСТРУМЕНТАМ ВСТАВКИ]
5.) Инструменты > Привязать к процессу (или начать с отладки)
6.) Запустите программу, к которой вы подключаетесь, и запустите ее так, чтобы ваш код попал
При подключении к nunit.exe откройте NUnit и запустите тест, чтобы ваша точка останова попала
При подключении к w3wp.exe(сайту IIS) откройте свой сайт в браузере и перейдите на страницу, которая попадет в точку останова
Сегодня я заметил, что если вы попытаетесь отладить проект, который не задан в качестве запуска, он покажет это. Когда вы присоединяетесь к процессу w3wp.exe, он думает о его отладке в проекте, который задан как начальный проект. Чтобы решить проблему, просто нажмите правой кнопкой мыши проект веб-приложения и выберите "Задать как запуск проекта". Затем попробуйте повторно подключиться к вашему процессу.
Сценарий таков: конкретный проект - ваш проект запуска (например, имеет метод Main). Этот проект ссылается на другие проекты в вашем решении. Точки останова в других проектах не попадают.
Быстрое решение: при создании своего решения загляните в путь сборки сборки (обычно bin\Debug) для запуска проекта. Посмотрите файлы DLL и PDB для проектов, на которые вы ссылаетесь. Убедитесь, что их последняя измененная дата - это дата, когда вы в последний раз создали свое решение. Если это не так, то скопируйте их из пути сборки Build для каждого проекта в ваши проекты запуска. Создайте путь вывода. Например:
В проекте A есть Main. Он ссылается на проект B. Ваши контрольные точки не попадают в проект B. Скопируйте DLL и PDB файл из выходного пути Project B Build к пути выхода проекта A Build. Затем запустите свое решение. Теперь точка останова будет удалена.
Теперь вам нужно выяснить, почему Project A не копирует файлы Project B DLL и PDB. Ответы здесь охватывают большинство сценариев. Один из сценариев, которые не затрагиваются, - это убедиться, что ваши проекты и решения привязаны к TFS правильно. У меня были некоторые проекты, привязанные, а некоторые не привязаны правильно. Это вызвало у меня проблему. Как только я исправил это, проблема исчезла, и мне больше не пришлось копировать файлы DLL и PDB.
Решениями по той же проблеме в моем случае была следующая комбинация шагов:
Чтобы исправить эту проблему в Web.config, мне просто пришлось добавить debug="true"
<system.web>
<compilation targetFramework="4.0" debug="true">
Что помогло мне найти это решение, он смотрел на окна Модули во время отладки и видел, что для моих загружаемых DLL-библиотек ASP.NET я имел: Binary не был создан с информацией об отладке.
У меня была та же проблема, но в VS2013 для веб-приложения. Для меня ответ состоял в том, чтобы обновить конфигурацию сборки для решения: -
Как только я это сделал, все мои точки останова начали работать.
Хорошо - здесь мы идем:
(В "приложении Silverlight": сначала проверьте, что silverlight проверяется в "веб" в вашем проекте проекта "properties" - если это не решило его, попробуйте это ниже)
В первый раз: запустите это сначала: devenv.exe/ResetSettings а также 1: В верхнем меню нажмите на тег отладки 2: параметры и настройки кликов 3: В разделе "отладка" и под "общим" найдите "enable.net source source stepping", 4: Поставьте галочку. 5: И теперь все символы будут загружены и переконфигурированы:)
Если это повторится после вышеописанного, просто очистите папку, в которой находятся символы:
1: В верхнем меню нажмите на тег отладки 2: параметры и настройки кликов 3: В "отладке" и под "символами" найдите кнопку "пустой кеш символов" и щелкните по ней.
Откройте URL-адрес веб-приложения из браузера, а затем в среде ID VS.Net используйте Tools → AttachtoProcess
затем присоединяется к aspnet_wp.exe.
Отладчик начнет работать
Я попытался переименовать файл .pdb
в папку obj\debug
и сделал чистое решение и перестроил.
Он создал новый файл .pdb
, и я смог правильно ударить точки останова.
Мне пришлось вручную удалить все экземпляры .dll из реестра и все экземпляры .dll с моего локального диска. Удалено/переустановлено мое приложение и теперь im удары точки останова! Потерпел полдня, делая это: (.
У меня была такая же проблема - я потерял много времени, пытаясь получить отладку, работающую в Visual Studio.
В итоге это был Nuget - у меня было 3 версии Newtonsoft.Json(через 7 проектов С#). Решение будет скомпилировано, но не будет отлаживаться.
Я исправил проблему, выполнив следующую команду в консоли диспетчера пакетов Nuget:
PM > Обновление пакета Newtonsoft.Json
В моем приложении WPF я удалил папку приложения, снова "Получил последний" из исходного контроля и перестроил. Все точки останова отлично работают.
Попробуйте установить Silverlight Application Project как проект запуска: щелкните правой кнопкой мыши по проекту → 'Установить как проект запуска. Затем нажмите F5 и посмотрите, можете ли вы поймать точки останова...
Попробуйте удалять данные о просмотре/темпе в вашем браузере каждый раз, когда вы вносите изменения в приложение Silverlight
Еще один анекдот, который может быть полезен -
Я столкнулся с этой проблемой, когда один из моих проектов использовал ссылки на файлы из выходной папки Release. Когда результаты сборки были помещены в папку "Товары", эти выпуски dll перезаписывали DLL файлы Debug.
Решение заключалось в том, чтобы убедиться в файле csproj, моя ссылка HintPath была
<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>
а не
<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>
У меня была та же проблема. После меня работали
Перейдите к web application --> Properties --> Silverlight Applications
Если вы не видите приложение Silverlight в списке, нажмите "Добавить" и выберите приложение Silverlight из раскрывающегося списка "Проект" и добавьте его.
У меня возникла такая проблема, когда на клиенте, где для каждого решения приложения они скопировали большинство разделяемых сборок в папку "Ссылки" , затем добавили их в решение как "Элементы решения" и как "Проект" в рамках решения.
Не уверен, почему, но некоторые из них были отлаживаемы, а некоторые нет, хотя в настройках "Ссылки" для собраний были указаны правильные полные пути.
Это непредсказуемое поведение alomst сводило меня с ума:)
Я решил это, удалив все сборки из папки "Ссылки" , для которых были проекты с исходным кодом, и очень хорошо отслеживал информацию о версии для общих сборок.