Хорошо, что у меня есть:
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 и его файлы отладки находятся внутри отлаживаемого приложения, и вы сможете пройти через код.
Если вы отлаживаете веб-проект, убедитесь, что в файле web.config установлен атрибут debug = "true":
<system.web>
<compilation debug="true" .../>
У меня была такая же проблема в Windows 7 и пробовали все: очищенные библиотеки DLL, список исследуемых модулей, отключили "Just My Code" и т.д.
Проблема была решена после запуска Visual Studio "как администратора". Честно. Почему Microsoft не может просто предупредить меня, что он не работает "как администратор"? Это сэкономит мне несколько часов работы.
Для меня проблема заключалась в том, что я включил "Оптимизировать код" на вкладке "Сборка" моих настроек проекта.
Отладка → Присоединить к процессу →
выберите Отладить следующие типы кода: →
выберите Управляемый v3.5, v3.0, v2.0 или Управляемый v4.5, v4.0
Была та же проблема
По какой-то причине одна из DLL была зарегистрирована в GAC, поэтому она всегда отличалась от кода.
Как только я удалил его из GAC, проблема была решена.
Для тех, кто использует 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 для веб-приложения. Для меня ответ состоял в том, чтобы обновить конфигурацию сборки для решения: -
Как только я это сделал, все мои точки останова начали работать.
В моем приложении WPF я удалил папку приложения, снова "Получил последний" из исходного контроля и перестроил. Все точки останова отлично работают.
У меня была такая же проблема - я потерял много времени, пытаясь получить отладку, работающую в Visual Studio.
В итоге это был Nuget - у меня было 3 версии Newtonsoft.Json(через 7 проектов С#). Решение будет скомпилировано, но не будет отлаживаться.
Я исправил проблему, выполнив следующую команду в консоли диспетчера пакетов Nuget:
PM > Обновление пакета Newtonsoft.Json
Мне пришлось вручную удалить все экземпляры .dll из реестра и все экземпляры .dll с моего локального диска. Удалено/переустановлено мое приложение и теперь im удары точки останова! Потерпел полдня, делая это: (.
Я попытался переименовать файл .pdb
в папку obj\debug
и сделал чистое решение и перестроил.
Он создал новый файл .pdb
, и я смог правильно ударить точки останова.
Откройте URL-адрес веб-приложения из браузера, а затем в среде ID VS.Net используйте Tools → AttachtoProcess
затем присоединяется к aspnet_wp.exe.
Отладчик начнет работать
Хорошо - здесь мы идем:
(В "приложении Silverlight": сначала проверьте, что silverlight проверяется в "веб" в вашем проекте проекта "properties" - если это не решило его, попробуйте это ниже)
В первый раз: запустите это сначала: devenv.exe/ResetSettings а также 1: В верхнем меню нажмите на тег отладки 2: параметры и настройки кликов 3: В разделе "отладка" и под "общим" найдите "enable.net source source stepping", 4: Поставьте галочку. 5: И теперь все символы будут загружены и переконфигурированы:)
Если это повторится после вышеописанного, просто очистите папку, в которой находятся символы:
1: В верхнем меню нажмите на тег отладки 2: параметры и настройки кликов 3: В "отладке" и под "символами" найдите кнопку "пустой кеш символов" и щелкните по ней.
Во что бы то ни стало отметьте это для не-бытия-ответа, но эта проблема точек останова, которые не ударяются, для меня просто исправлена. После нескольких часов удаления временных файлов, перезагрузки, переустановки, аркирования с настройками отладки безрезультатно, он просто начал работать. Я был на грани безумия, когда, без всякой причины, мы попали в точку останова. Люблю непоследовательные ошибки, я.
Пожалуйста, проверьте веб-свойства веб-проекта (Asp.Net), на котором размещается ваш xlightlight silverlight. Перейти к веб-проекту Хостинг Silverlight xap → Свойства → Веб → Раздел отладчиков → Убедитесь, что установлен флажок silverlight.
Удалите файл .xap, если ваша точка останова не пострадает. Внутри YourProject.Web/ClientBin Удалить YourProject.xap. Я пробовал все выше и наткнулся на это исправление, работает каждый раз. Мудрый очистить проект после удаления также.
Я использую VS 2008, и я получил эту ошибку. Я попробовал все, что предлагалось здесь и на некоторых других веб-сайтах, но ничего не получилось.
Решение было довольно простым, и на этой странице было упомянуто еще два решения, которые поставили меня в нужную область.
Перейдите в меню "Проект" и нажмите "Свойства" (вы также можете щелкнуть правой кнопкой мыши по имени проекта в обозревателе решений и выбрать "Свойства" ).
Выберите вкладку "Компилировать" слева.
В текстовом поле "Создать выходной путь:" убедитесь, что у вас есть "bin" в текстовом поле.
В моей ситуации он указывал на другую папку bin в сети, и это то, что заставило точки останова терпеть неудачу. Вы хотите, чтобы он смотрел вашу текущую папку Bin вашего проекта.
У меня была аналогичная проблема, кроме моей проблемы было глупо - у меня было 2 экземпляра встроенного веб-сервера, работающего под двумя разными портами, и у меня был мой проект → свойства → веб → "Стартовый URL" , указывающий на фиксированный порт, но веб-приложение фактически не было запущено под этим портом. Поэтому мой браузер перенаправлялся на "Стартовый URL" , который упоминался в 1539, но экземпляр кода/отладки работал под портом 50803.
Я изменил встроенный веб-сервер для работы под фиксированным портом и скорректировал свой "Стартовый URL" , чтобы использовать этот порт. project → properties → web → "Серверы" → "Использовать сервер разработки Visual Studio" → конкретный порт
У меня возникла такая проблема, когда на клиенте, где для каждого решения приложения они скопировали большинство разделяемых сборок в папку "Ссылки" , затем добавили их в решение как "Элементы решения" и как "Проект" в рамках решения.
Не уверен, почему, но некоторые из них были отлаживаемы, а некоторые нет, хотя в настройках "Ссылки" для собраний были указаны правильные полные пути.
Это непредсказуемое поведение alomst сводило меня с ума:)
Я решил это, удалив все сборки из папки "Ссылки" , для которых были проекты с исходным кодом, и очень хорошо отслеживал информацию о версии для общих сборок.
У меня была та же проблема. После меня работали
Перейдите к web application --> Properties --> Silverlight Applications
Если вы не видите приложение Silverlight в списке, нажмите "Добавить" и выберите приложение Silverlight из раскрывающегося списка "Проект" и добавьте его.
Еще один анекдот, который может быть полезен -
Я столкнулся с этой проблемой, когда один из моих проектов использовал ссылки на файлы из выходной папки Release. Когда результаты сборки были помещены в папку "Товары", эти выпуски dll перезаписывали DLL файлы Debug.
Решение заключалось в том, чтобы убедиться в файле csproj, моя ссылка HintPath была
<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>
а не
<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>
Попробуйте установить Silverlight Application Project как проект запуска: щелкните правой кнопкой мыши по проекту → 'Установить как проект запуска. Затем нажмите F5 и посмотрите, можете ли вы поймать точки останова...
Попробуйте удалять данные о просмотре/темпе в вашем браузере каждый раз, когда вы вносите изменения в приложение Silverlight
Когда-нибудь щелкните правой кнопкой мыши точку останова → Местоположение → проверка для меня, чтобы исходный код отличался от исходной версии.
[EDIT]: Иногда также восстанавливается полное решение.
Эта ошибка также может возникать при удаленной отладке, если вы не отлаживаете самую последнюю версию. Когда вы выполняете удаленную отладку, не забудьте переместить новый код на удаленный компьютер после (повторного) создания на вашем локальном компьютере-разработчике!
То, что я сделал, чтобы исправить эту проблему, было на странице, где моя точка останова не попала, я выбрал папку > добавить существующий элемент и затем выбрать элемент из его пути сохранения. Это позволило начать работу с точкой останова.
Одним из возможных сценариев является то, что если ваш проект ASP ссылается на некоторый код в приложении (а не на dll), символы не будут загружаться.
Мне пришлось временно менять указанное приложение в библиотеку классов, когда я отлаживал код.
Я взял самый простой путь, фактически в решении нескольких проектов, включая одну библиотеку классов. У меня возникла проблема с DLL файлом, созданным этим проектом библиотеки классов, который не позволял мне выполнять контрольные точки во время выполнения, поскольку это было не строя по какой-то причине, я отдельно создаю этот проект и ссылаюсь на него .dll и теперь точки останова функциональны
Не уверен, может быть, это поможет вам; если не вы, то кто-то новый, как я, только потому, что он работал у меня:)
Это обычная проблема, если отладка отключена приложением и часто запускается, если у вас есть несколько преобразований на web.config... Один из способов решить это - перейти в "Сборка" > "Диспетчер конфигурации" и убедиться, что Конфигурация Debug настроена для запуска... Довольно часто, чтобы перейти от тестирования одного преобразования к другому и, таким образом, потеря способности к разрыву в определенных точках.
Этот ответ конкретно не связан с Silverlight, но общая ошибка: точка останова в настоящий момент не будет удалена. Для этого документа не были загружены никакие символы. Ошибка noob заключается в том, что проект не задан как отладка в диспетчере конфигурации. Стоит проверить
Я отлаживаю присоединение к IIS. Я захватил создание web.config для некоторых новых настроек и забыл обновить web.config, чтобы включить отладку.
Убедитесь, что для элемента отладки установлено значение true. Другими словами:
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
У меня была эта проблема, но в моем случае это было из-за задержки загрузки модуля, который я пытался отлаживать. У меня была DLL, связанная с моим основным проектом, и DLL - это то, что я отлаживал. DLL вызывалась только тогда, когда вызывались определенные функции в главном приложении, поэтому VS2010 не загружал модуль до тех пор, пока эти функции не были вызваны.
Когда я начал проект, я получил это сообщение, но к тому моменту, когда я выполнил эту функцию, отладчик загрузил модуль и соответствующую информацию об отладке.
Эта тема очень помогла мне: http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
Это такой полезный поток, контрольный список вещей, чтобы попробовать эту пагубную проблему. Для меня тот, кто работал, менял IE. Мне потребовалось некоторое время, чтобы понять, поскольку я уже использовал IE, у меня были свойства веб-проекта проекта, так что начальное действие заключалось в том, чтобы запустить программу extenal
C:\Program Files (x86)\Internet Explorer\iexplore.exe
с аргументами командной строки
http://localhost/MyProject -private
Мне нужен флаг -private, чтобы остановить кеширование IE swf, над которым я работаю. Переход на "конкретную страницу" из "начальной внешней программы" исправил проблему "без символов" для меня.
Я много пробовал. Что сработало для меня. Я сделал приложение Silverlight "Set as Startup Project", щелкнув правой кнопкой мыши по проекту. Затем я попытался запустить его (что явно не удалось, поскольку он полагался на службы RIA на веб-сервер, который не был запущен) И затем я reset веб-проект как проект запуска... и hey presto.. все работает.
Если у вас возникли проблемы с проектами Silverlight, решение может быть довольно простым. Согласно моему опыту, во многих случаях отладка символов не загружается из-за того, что новые файлы ".xap" не разворачиваются во временную папку (либо внутренние VS Cassini, либо IIS Express). В этой ситуации полные перестройки или сброс настроек VS не помогут. Самое простое решение - просто удалить временные интернет файлы в вашем браузере. Если вы используете IE для разработки и тестирования Silverlight, я бы рекомендовал включить опцию "Удалить историю просмотров при выходе", чтобы не иметь таких проблем в будущем.
Моя проблема была "возвратной" серединой кода. поэтому после возвращения ошибка не будет работать.
Вот как я исправил свою проблему после клонирования в разные репозитории для Visual Studio 2015:
В Visual Studio: