Файл исходного кода отличается от того который использовался при построении модуля
Несмотря на то, что ничего не было выделено, проект в моем браузере работал нормально. Поэтому я решил запустить отладчик, чтобы убедиться, что все действительно работает так, как должно быть.
Из-за этого я не могу протестировать код, который написал сегодня.
- Как может исходный код отличаться от бинарного, когда я только что выполнил его?
- Есть ли какой-то способ вбить смысл в визуальную студию, или я просто что-то упускаю?
Извините, если это было слишком. Краткая версия: я компилирую свою программу, затем пытаюсь ее отладить, и Visual Studio сообщает мне, что мой исходный файл (который я только что скомпилировал) отличается от модуля, который я только что создал. Я просто хочу знать, почему он так думает
Я столкнулся с этой проблемой при запуске консольного приложения, где источником, который отличался, был источник с точкой входа (static void Main). Удаление каталогов bin и obj и выполнение полной перестройки, казалось, исправили это, но каждый раз, когда я вносил изменения в код, он снова устарел.
Причина, которую я нашел для этого, была:
- Я установил флажок «Только создавать стартовые проекты и зависимости при запуске» (Инструменты -> Параметры -> Проекты и решения -> Сборка и запуск)
- В диспетчере конфигураций мой стартовый проект не отмечен флажком "Сборка"
(Для № 2 -> доступно через панель инструментов в раскрывающемся списке «Отладка/выпуск».)
У меня было несколько веток решения в TFS. Удаление каталогов bin и obj во всех проверенных ветках, казалось, прояснило ситуацию.
В моем случае я по ошибке изменил solution platforms с Any CPU на Mixed Platform . Я верну его обратно на Any CPU , и он снова заработает.
Спасибо, Решение > Свойства > Свойства конфигурации > Конфигурация, мое консольное приложение (которое запускает тесты для веб-приложения в том же sln) было снято.
У меня была такая же проблема, все мои проекты были в одном и том же решении, поэтому они использовали ссылки Project to Project, поэтому, когда один изменился, другие должны были быть обновлены. Однако это было не так, я попытался собрать, пересобрать, закрыть VS2010, вытащил новую копию из нашего контроля версий. Ничего из этого не сработало, и в конце концов я попытался щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект по отдельности. Это обновило файлы .dll и .pdb, чтобы я мог выполнять отладку.
Проблема здесь в том, что ваши файлы dll и pdb не синхронизированы.
Это сработало для меня:> Ничего из этого не сработало, и в конце концов я попытался щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект по отдельности. Это обновило файлы .dll и .pdb, чтобы я мог выполнять отладку.
Выгрузить проект (перезагрузить снова) и опубликовать последние биты на веб-сервере (IIS) работает для меня.
Эта проблема возникла у меня, когда я скопировал и вставил program.cs, тогда как модуль и проект, я думаю, не синхронизированы. Я щелкнул правой кнопкой мыши имя проекта в обозревателе решений и очистил проект. А затем щелкните правой кнопкой мыши и построили его. Потом работал нормально. Был бы признателен, если бы кто-то дал четкое объяснение по моему сценарию.
Следуй этим шагам
- Просто удалите каталог bin из проекта, в котором создается DLL.
- Восстановите проект.
- Удалите ссылку из проекта, которая ссылается на DLL.
- Включите снова ссылку.
- Наслаждаться.
В дополнение к этим ответам у меня была такая же проблема при замене новых DLL на старые из-за неправильного пути. Если вы все еще получаете эту ошибку, возможно, вы указали неправильный путь для DLL. Перейдите в диспетчер IIS и щелкните веб-сайт, который использует ваши библиотеки DLL. В правом окне нажмите «Дополнительные настройки» и перейдите к папке «Физический путь» в проводнике и убедитесь, что вы используете эту папку для замены своих библиотек DLL.
С веб-службами проблема может быть вызвана использованием команды Visual Studio «Просмотреть в браузере». Это помещает файлы DLL и PDB службы в папки bin и obj. При входе в веб-службу из клиента Visual Studio каким-то образом использует PDB в папке bin (или obj), но использует DLL в выходной папке сборки проекта. Есть пара обходных путей:
- Попробуйте удалить файлы DLL и PDB в файлах bin и obj веб-службы.
- Попробуйте нажать «Просмотреть в браузере» в Visual Studio.
Если вы ранее получили ошибку несоответствия исходного файла, Visual Studio могла добавить имя файла в черный список. Проверьте свойства вашего решения. Выберите «Общие свойства -> Исходные файлы отладки» в левой части диалогового окна. Если исходные файлы вашего веб-сервиса отображаются в поле «Не искать эти исходные файлы», удалите их.
У меня была эта проблема.
Я пробовал все вышеперечисленное, но сработало только это:
- удалите файл .pdb для решения.
- удалите оскорбительные файлы .obj (для файла, о котором сообщается, что он не синхронизирован)
Это исправило проблему для всех сборок, продвигающихся вперед для меня.
Я думаю, что удаление файлов .pdb является ключевым здесь. Это произошло со мной, потому что я скопировал устаревшие файлы .pdb из другой ветки.
Вот как я исправил проблему в Visual Studio 2010:
1) Измените параметр «Конфигурации решений» с «Отладка» на «Выпуск».
2) Начать отладку
3) Остановите отладку и переключите параметр «Конфигурации решений» обратно на «Отладка».
Это сработало для меня. Шаг 3 является необязательным - он работал нормально, когда я изменил его на «Выпуск», но я хотел изменить его обратно.
Я включил существующий проект из другого решения в новый файл решения.
Я не заметил, что когда существующий проект был перестроен, он помещал окончательный вывод в выходной каталог НОВОГО решения. У меня был определен путь компоновщика для просмотра выходного каталога СТАРОГО решения.
Переключение моего проекта на поиск в выходном каталоге нового решения устранило эту проблему для меня.
У меня была эта проблема, и оказалось, что я запускал свое консольное приложение как приложение Windows. Переключение типа вывода обратно на консоль устранило проблему.
Выгрузите проект, содержащий файл, вызывающий ошибку.
Моя проблема заключалась в том, что у меня было два проекта в моем решении. Второй был тестовым проектом, который использовался для вызова первого. Я выбрал путь к ссылкам из папки релиза папки bin.
Поэтому всякий раз, когда я вносил изменения в код первого проекта и перестраивал его, он обновлял библиотеки DLL в папке отладки, но вызывающий проект указывал на папку выпуска, что давало мне ошибку: «Исходный файл отличается от того, когда модуль был построен."
Как только я удалил ссылку на dll основного проекта в папке выпуска и установил ее в dll в папке отладки, проблема исчезла.
В моем случае ответ @Eliott не работает. Чтобы решить эту проблему, мне пришлось исключить/включить из проекта мой дефектный файл, а также очистить и перестроить решение.
После этих действий мой файл с моими последними изменениями и отладчик восстанавливаются.
Надеюсь, это поможет.
Решение: - проблема заключается в следующем: - если ваши некоторые проекты в решении ссылаются на некоторые другие проекты, то иногда dll некоторых проектов не будет обновляться автоматически, всякий раз, когда вы создаете решение, некоторые проекты будут иметь предыдущие dll сборки, а не последние DLL
Вам нужно пойти вручную и скопировать dll последнего проекта сборки в указанный проект
Я использовал Visual Studio 2013, и у меня был существующий проект в системе управления версиями.
Я загрузил свежую копию из системы управления версиями в новый каталог.
После внесения изменений в новую копию при сборке я получил указанную ошибку.
Мое решение:
1) Откройте Documents\IISExpress\config\applicationhost.config
2) Обновите узел virtualDirectory с каталогом до новой копии и сохраните.
Моя проблема заключалась в том, что у меня был веб-сервис в проекте, и я изменил путь сборки.
Восстановление пути сборки по умолчанию решило мою проблему.
У меня была такая же проблема, и я следовал большинству указаний в других ответах, опубликованных здесь, и у меня ничего не получалось.
В конце концов я открыл IIS и переработал пул приложений для своего веб-приложения. У меня IIS версии 8.5.9600, я щелкнул правой кнопкой мыши свое веб-приложение, затем: Развернуть > Перезапустить > Перезапустить пул приложений > ОК.
Это, кажется, исправило это, точки останова теперь срабатывают, как и ожидалось. Я думаю, что это вместе с удалением папок bin и obj помогло моей ситуации.
Я также испытал это. Я просто открываю папку obj в проекте, а затем открываю папку отладки, удаляю файл .pdb и все.
Эта ошибка также возникает, если вы пытаетесь внести изменения в исходный файл, который не является частью проекта.
Я отлаживал метод из .dll другого моего проекта, где Visual Studio весьма полезно загрузила исходный код, поскольку .dll была собрана на той же машине и знала путь к исходному коду. Очевидно, что изменение такого файла ничего не даст, если только вы не перестроите указанный проект.
- Удалить все точки останова.
- Перестроить .
- Выполнено
В Visual Studio 2015, используя C++, для меня была устранена проблема the source file is different from when the module was built :
Отладка->запустить без отладки.
Этот вариант у меня работал. Надеюсь это поможет!
Проверьте правильность местоположения, на которое вы указали с помощью mex() в Matlab (содержит файлы lib и obj, которые были изменены до последней даты, когда вы скомпилировали библиотеку в Visual Studio).
Если это не так:
Убедитесь, что вы компилируете Visual Studio в режиме, сохраняющем файлы .lib:
свойства -> свойства конфигурации -> общие -> тип конфигурации -> статическая библиотека
свойства -> свойства конфигурации -> общие -> целевое расширение = .lib (вместо exe)
Убедитесь, что выходные и промежуточные каталоги соответствуют каталогу Matlab в
- свойства -> свойства конфигурации -> общие -> выходной каталог
- свойства -> свойства конфигурации -> общие -> промежуточный каталог
Я получаю эту проблему при отладке иногда с помощью Visual Studio, но когда приложение обслуживается IIS. (мы должны разрабатывать в этой форме по некоторым сложным причинам, которые связаны с тем, как первоначальный разработчик настроил этот проект.)
Когда я изменяю файл и перестраиваю, это в большинстве случаев помогает. Я знаю, это звучит глупо, но я просто пытался отладить какой-то код, чтобы понять, почему он делает что-то странное, когда я не менял его некоторое время, и я попробовал дюжину вещей с этой страницы, но это было исправлено, просто изменив файл..
Некоторые вещи для вас, чтобы проверить:
Вы дважды проверяли ссылки на свои проекты?
У вас есть запущенный веб-сервер Visual Studio? Проверьте системный трей и найдите страницу со значком шестеренки (у вас может быть несколько):
Щелкните правой кнопкой мыши и закройте / выйдите из него. У вас может быть больше одного. Можете ли вы отлаживать свои изменения сейчас?
Вы используете отладочную версию, но собрали только релизную версию (или наоборот)?
Компиляции преуспевают. Я немного нуб, когда дело доходит до Visual Studio. Как проверить, использую ли я отладочную версию или выпуск?
- Я просто пытался исключить очевидное. Чтобы проверить, находитесь ли вы в выпуске или отладке, проверьте раскрывающийся список рядом со значком «отладка» на панели инструментов. Это будет либо «Отладка», либо «Выпуск».
Мне было интересно: при установке чего-то есть простой способ двойного щелчка по исполняемому файлу установки, а с другой стороны, есть способ собрать его из исходного кода.
Последний, загружающий исходный пакет, действительно громоздок.
Но в чем принципиальная разница между этими двумя методами?
Все программное обеспечение является программами , которые также называются исходными пакетами . Таким образом, все исходные пакеты должны быть собраны в первую очередь для запуска в вашей системе.
Эти бинарные пакеты являются один, которые уже строит из источника кто - то с общими функциями и параметрами, в программном обеспечении , так что большое количество пользователей может установить и использовать его.
Бинарные пакеты просты в установке .
Но, возможно, не все варианты из пакета upstream.
Таким образом, для установки из исходного кода вам необходимо создать исходный код самостоятельно. Это означает, что вам нужно заботиться о зависимостях самостоятельно. Также вам необходимо знать все функции пакета, чтобы вы могли его соответствующим образом собрать.
Преимущества установки из источника:
- Вы можете установить последнюю версию и всегда оставаться в курсе, будь то исправление безопасности или новая функция.
- Позволяет вам обрезать функции при установке в соответствии с вашими потребностями.
- Точно так же вы можете добавить некоторые функции, которые могут отсутствовать в двоичном файле.
- Установите его в желаемом месте.
- В случае некоторого программного обеспечения вы можете предоставить информацию о вашем оборудовании для соответствующей установки.
Короче говоря, установка из исходного кода дает вам возможность большой настройки, в то же время это требует больших усилий, в то время как установка из бинарного файла проще, но вы не сможете настроить ее так, как хотите.
Обновление : добавление аргумента, относящегося к безопасности, в комментариях ниже. Да, это правда, что при установке из двоичного файла у вас нет целостности исходного кода. Но тогда это зависит от того, откуда у вас бинарный файл. Существует множество надежных источников, из которых вы можете получить бинарный файл любого нового проекта, единственным минусом является время . Для того, чтобы бинарный файл обновлений или даже новый проект появился в наших доверенных репозиториях, может потребоваться некоторое время.
И, прежде всего, о безопасности программного обеспечения, я хотел бы выделить эту веселую страницу в Bell-Labs, предоставленную Джо в комментариях ниже.
Исходный код также может быть скомпилирован оптимизированным образом для вашей системы (что .. может быть не очень хорошая идея, так как скомпилированный материал «специфичен» для системы и может не работать на резервном . но у вас есть источник, вы можете перекомпилировать (если у вас есть время для этого))
Это зависит от того, есть ли у вас такая «резервная система». Если вы просто проводите какие-то исследования, вы обычно этого не делаете.
Для гиперпараноида одним из преимуществ установки из исходного кода является безопасность и возможность просмотра кода, если вы можете и хотите это делать: когда вы устанавливаете из исходного кода, вы точно знаете, что у вас есть двоичный файл из этого исходного кода, а не бинарный файл с неизвестными модификациями (при условии, что вы доверяете источнику в первую очередь).
Исходный файл содержит исходный код, написанный разработчиком на любом языке, который он / она выбирает (C, C ++, Python и т. Д.), И является универсальным. Это не относится ни к одному дистрибутиву, а во многих случаях к любой операционной системе.
Пакет (например, RPM или DEB) - это двоичный исполняемый файл (или интерпретируемый скрипт и т. Д.), Предварительно подготовленный для вашего конкретного дистрибутива. Задача подготовки исходного кода для компиляции (добавления необходимых исправлений и т. Д.), Фактической компиляции, создания специфических для дистрибутива конфигурационных файлов, создания сценариев до и после установки и т. Д. Выполняется для вас сопровождающим пакета.
Другими словами, вся работа с ослом была выполнена для вас в пакете, в то время как вам придется делать это самостоятельно, если вы решите установить из исходного кода.
Практически во всех случаях использовать пакет намного проще:
Однако иногда упакованная версия является старой версией или, что еще хуже, упакованной версии не существует; в этом случае ваш единственный вариант - собрать себя. Если вы это сделаете, вам нужно учитывать следующее:
- Вам нужно будет установить все инструменты разработчика в вашей системе
- Вы будете нести ответственность за проверку обновлений и перекомпиляцию
- Вам нужно будет убедиться, что все зависимости установлены, включая dev пакеты - их может быть много.
- Возможно, вам придется отлаживать проблемы, если они не работают должным образом в вашем дистрибутиве.
Если вы готовы приложить дополнительные усилия, то компиляция из исходного кода может дать вам следующие преимущества:
- Доступ к последней доступной версии
- Опция оптимизации процесса компиляции для производительности / стабильности
- Наслаждение!
Обратите внимание, что, хотя в готовых пакетах некоторых дистрибутивов предусмотрены двоичные исполняемые файлы, которые готовы к установке и запуску (например, RPM и DEB), другие дистрибутивы предоставляют пакеты, которые просто автоматизируют процесс компиляции.
ebuilds Примером этого является Gentoo - пакет - это в основном инструкции для менеджера пакетов, описывающие, как скомпилировать и установить исполняемый файл. Это имеет много преимуществ традиционных менеджеров пакетов (автоматическое обновление, удаление и т. Д.), В то же время позволяя пользователю оптимизировать процесс компиляции по своему вкусу.
Arch Linux имеет систему упаковки, в которой основные пакеты являются двоичными, тогда как многие дополнительные пакеты компилируются в системе с использованием PKGBUILD файлов.
Несмотря на то, что ничего не было выделено, казалось, что проект в моем браузере работает нормально. Поэтому я решил запустить отладчик, чтобы проверить, действительно ли все работает так, как должно.
Я очищал решение и перестраивал его несколько раз, удалял файлы tmp, следовал всем указанным здесь инструкциям. Получение «Исходный файл отличается от того, когда был построен модуль». , перезапустил веб-сервер и по-прежнему сообщает мне, что исходные файлы отличаются, хотя это явно не так.
Из-за этого я не могу протестировать какой-либо код, который написал сегодня.
- Как исходный код может отличаться от двоичного, если я только что его выполнил?
- Есть ли способ придать смысл визуальной студии, или я просто чего-то упускаю?
Извините, если это было многовато. Краткая версия: я компилирую свою программу, затем пытаюсь отладить ее, и Visual Studio сообщает мне, что мой исходный файл (который я только что скомпилировал) отличается от модуля, который я только что построил. Я просто хочу знать, почему он так думает
У меня возникла эта проблема при запуске консольного приложения, в котором источник, который отличался, был источником с точкой входа (static void Main). Удаление каталогов bin и obj и выполнение полной перестройки, казалось, исправили это, но каждый раз, когда я вносил изменение в код, он снова становился устаревшим.
Причина, по которой я это нашел:
- Я проверил «Создавать только запускаемые проекты и зависимости при запуске» (Инструменты -> Параметры -> Проекты и решения -> Сборка и запуск)
- В Configuration Manager в моем стартовом проекте не отмечена отметка "Сборка"
(Для №2 -> доступно через панель инструментов в раскрывающемся списке «Отладка / Выпуск».)
У меня было несколько веток решения в TFS. Удаление каталогов bin и obj во всех проверенных ветках, похоже, прояснило ситуацию.
в моем случае я был изменен solution platforms с Any CPU на Mixed Platform по ошибке . Я снова меняю его на, Any CPU и он снова работает.
Спасибо, Решение> Свойства> Свойства конфигурации> Конфигурация, мое консольное приложение (которое запускает тесты для веб-приложения в том же sln) не было отмечено.
У меня была такая же проблема, все мои проекты были в одном решении, поэтому они использовали ссылки Project to Project, так что, если один изменил, другие должны были быть обновлены. Однако это было не так, я попытался собрать, перестроить, закрыть VS2010, вытащил новую копию из нашего источника. Ничего из этого не сработало, в конце концов я попробовал щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект индивидуально. Это обновило файлы .dlls и .pdb, чтобы я мог выполнять отладку.
Проблема здесь в том, что ваши файлы dll и / или pdb не синхронизированы.
это сработало для меня:> Ничего из этого не сработало, в конце концов я попробовал щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект индивидуально. Это обновило файлы .dlls и .pdb, чтобы я мог выполнять отладку.
выгрузить проект (перезагрузить снова) и опубликовать последние биты на веб-сервере (IIS) работает для меня.
Следуй этим шагам
- Просто удалите каталог bin из проекта, в котором создается DLL.
- Восстановите проект.
- Удалите ссылку из проекта, которая ссылается на DLL.
- Включите снова ссылку.
- Наслаждаться.
В дополнение к этим ответам у меня была такая же проблема при замене новых DLL на старые из-за неправильного пути. Если вы все еще получаете эту ошибку, вы не можете указать неправильный путь для DLL. Перейдите в диспетчер IIS и щелкните веб-сайт, который использует ваши библиотеки DLL. В правом окне нажмите «Дополнительные параметры» и перейдите к папке «Физический путь» в проводнике и убедитесь, что вы используете эту папку для замены своих DLL.
Некоторые вещи, которые вам стоит проверить:
Вы дважды проверили ссылки на свои проекты?
У вас еще работает запущенный веб-сервер Visual Studio? Проверьте панель задач и найдите страницу со значком шестеренки (у вас может быть несколько):
Щелкните правой кнопкой мыши и закройте / выйдите из него. У вас может быть больше одного. Можете ли вы отладить свои изменения сейчас?
Вы используете отладочную версию, но создали только версию выпуска (или наоборот)?
Компиляция выполняется успешно. Когда дело касается Visual Studio, я немного новичок. Как мне проверить, использую ли я отладочную версию или выпуск?
@frustrated - я просто пытался избавиться от очевидного. Чтобы проверить, находитесь ли вы в стадии выпуска или отладки, проверьте раскрывающийся список рядом со значком «отладка» на панели инструментов. Это будет либо «Отладка», либо «Выпуск».
@frustrated - хорошее начало;). Вы можете «отлаживать» код выпуска, но это не так полезно, но здесь это не актуально. Это означает, что вы создаете (или, по крайней мере, должны создавать) и запускаете двоичные файлы отладки. Мне придется подумать еще немного - не видя проблему, ее немного сложно диагностировать.
«не видя на самом деле проблемы, это немного сложно диагностировать», - так я и подумал. Я действительно ценю помощь
С веб-службами проблема может быть вызвана использованием команды Visual Studio «Просмотр в браузере». Это поместит файлы DLL и PDB службы в папки bin и obj. При входе в веб-службу из клиента Visual Studio каким-то образом использует PDB в папке bin (или obj), но использует DLL в папке выходной сборки проекта. Есть пара обходных путей:
- Попробуйте удалить файлы DLL и PDB в bin и obj файлах веб-службы.
- Попробуйте щелкнуть «Просмотр в браузере» в Visual Studio.
Если вы ранее получали ошибку несоответствия исходного файла, Visual Studio могла добавить имя файла в черный список. Проверьте свойства вашего решения. Выберите «Общие свойства -> Отладка исходных файлов» в левой части диалогового окна. Если исходные файлы вашего веб-сервиса отображаются в поле «Не искать эти исходные файлы», удалите их.
При отладке в Visual Studio иногда я добавляю точку останова, но она пустая, и VS говорит: «В данный момент точка останова не будет достигнута. Исходный код отличается от исходной версии». Очевидно, это мешает мне отладить.
Это проект сайта. Там не должно быть необходимости явно строить его. Должен компилироваться при использовании. Я подозреваю, что VS не может создать сайт, но это не говорит мне об этом! Махеш - нет, все таки версия VS.
В моем случае .. У меня разные версии одного и того же кода (например, test.cs для Live-версии и devolopment-версии .. Когда я открыл devolopment-версию и установил точку останова на test.cs, я получил ту же ошибку, но я понял, что ставлю тест точки останова Класс .cs, связанный с живой версией sln, а не devolopment, поэтому проверьте, что cs уже находится в стадии разработки)
Как говорится, «исходный код отличается от оригинальной версии».
Щелкните правой кнопкой мыши папку проекта в обозревателе решений и выберите Clean . Создайте новую версию проекта, и точка останова снова заработает!
Использование чистой не всегда работает. Мне пришлось вручную удалить все в моей папке bin, чтобы заставить его работать снова.
Я закрыл VS, удалил все папки bin и obj, пересобрал все, дважды проверил конфигурации сборки, сборка прошла успешно. Нет кости. Простые вещи не должны быть такими сложными. >: |
Если вы не отметили проект DLL в конфигурации сборки Debug , ваш новый код никогда не будет собран!
Перейдите к Build --> Configuration Manager . (в VS2010) и проверьте, проверен ли проект с кодом, который вы пытаетесь отлаживать, на текущую конфигурацию сборки.
Спасибо за предложение, Оливер. Это определенно не происходит здесь, я заметил бы довольно быстро, если бы один из моих проектов не строился.
У меня была точно такая же проблема, только не было ничего непроверенного. это была просто сборка для x86 в этом диалоге, в то время как моя локальная машина - x64! Поэтому я выбрал Any CPU опцию, и она снова работает.
Удаление проектов из конфигурации отладки без уважительной причины должно быть кардинальным грехом, так как эта конфигурация вполне может использоваться машиной сборки CI (я знаю, что она здесь), так что в конечном итоге она может пройти, когда она потерпит неудачу. Я знаю, что это может быть одним из многих этапов сборки, но все же . @ Оливер Я надеюсь, что член команды купил тебе печенье! :)
У меня была эта проблема, когда я перешел на сборку для x86 вместо AnyCPU. Он удалил проекты из строя по неизвестной причине.
Для меня это было во время работы над проектом WebSite. После очистки этих временных папок я получил правильные ошибки компилятора:
Я наконец решил проблему, когда обнаружил, что файл класса, который я намеренно переместил в подпапку, каким-то образом появился в корневой папке. VS использовал это, пока я редактировал другое.
Просто подсказка: ввод %localappdata% в поле поиска приведет вас прямо к C:\Documents and Settings\%username%\AppData\Local
Ты когда-нибудь делал это?
Если вы отметили флажок и нажали «Да», вы запустите последнюю успешную сборку, даже если ваш проект не компилируется. Это означает, что всякий раз, когда вы устанавливаете точку останова, вы получите эту ошибку.
Попробуйте изменить это значение:
- инструменты
- Опции
- Проекты и Решения
- Построить и запустить
- При запуске, когда возникают ошибки сборки или развертывания: Не запускать
Я не думаю, что я сделал это. И все же спасибо за ссылку. Это дало мне понимание того, что означает эта подсказка!
Visual Studio имела эту возможность в течение десятилетий (по крайней мере, VS98 имел ее). Я никогда не понимал, почему кто-то захочет запустить последнюю успешную сборку. В конце концов, если бы это было то, что я хотел, я бы запустил его напрямую, так как я все равно не мог отлаживать. Не запускать был бы более разумный дефолт.
Я использовал его несколько раз для запуска проекта (по любой причине, например, просто чтобы показать кому-то еще), пока я все еще в процессе написания кода, который не будет компилироваться. Иногда это удобно. Лично я оставляю это отключенным.
Возможно, если бы они должны были показать своего начальника, когда он внезапно пришел. Они могут нажать F5 и быть похожим на «вы видите, это работает!»
Снимите флажок Требовать исходные файлы, чтобы точно соответствовать оригинальной версии
@Rachmad Это решение работает. Но это, кажется, не полное решение, потому что это означает, что наши исходные файлы не совсем соответствуют исходной версии
Это не решение этой проблемы, а обходной путь. Очевидно, я не хочу работать с устаревшими файлами в отладчике.
@ObiWan Не очевидно. Мне нравится вносить незначительные правки и продолжать отладку, даже зная, что исходный код и сборка различны.
Выберите « Отладка» в конфигурациях решения вместо выпуска
Это была моя проблема. Я скомпилировал в режиме отладки, изменил код, а затем запустил его в режиме выпуска. Неудивительно, что отладчик думал, что код был другим - символы отладки были другими. Когда я удалил папку bin, как предлагали другие, я получил ошибку «для этого документа не было загружено никаких символов». Только тогда я установил связь и пробился к этому ответу. Нужно больше голосов!
Возможно, что проект будет отключен для сборки даже в конфигурации сборки Debug. Требуется проверка конфигурации сборки, переключение между конфигурацией Debug / Release бессмысленно.
Это было и для меня. попытался очистить, перестроив другие упомянутые решения безрезультатно. Не заметил, что решение смотрело мне в лицо
Это то, что случилось со мной - я строил свой проект и заменял мои библиотеки снова и снова, но проблема просто не исчезла. Я понял, что код создается в режиме Release, когда я заменял dll из папки / bin / debug. Глупый я.
Я хотел присоединиться к процессу, который был построен в режиме выпуска. Переход на отладку решил мою проблему.
Обратите внимание на окно «Вывод» в VS. Он скажет вам, какие сборки загружены и когда. Вы можете видеть, что загружается более старая версия вашей сборки где-то в папке.
Например, если у вас есть несколько сборок, и вы в настоящее время пытаетесь разбить одну из вспомогательных сборок, CLR будет обрабатывать разрешение сборки, которое может загрузить другой файл сборки, чем тот, на который вы ссылались в проекте.
Также стоит иметь в виду, но я не думаю, что это проблема здесь, так как я пытаюсь взломать проект веб-сайта, а не библиотеку классов.
Закрытие Visual Studio и повторное открытие решения может решить проблему, то есть это ошибка в самой IDE (я использую VS2010).
Если у вас запущено более одного экземпляра Visual Studio, вам нужно только закрыть экземпляр, на котором запущено решение с проблемой.
Новый способ решения этой проблемы появился в Visual Studio 2017 с 15.3.1 по 15.3.5. Если вы используете EditorConfig , charset=utf8 опция вызывает эти симптомы. Команда VS воспроизвела это и говорит, что работает над этим .
Поэтому одно из исправлений - закомментировать вашу charset=utf8 строку в файле .editorconfig.
Изменить: это должно быть исправлено с VS 15.5.
Статус теперь «Фиксированный - ожидающий релиз» по состоянию на два дня назад (9 октября 2017 г.). Что является хорошей новостью, так как UTF-8 - единственное разумное значение по умолчанию для кодирования текста в наши дни. :-)
Я также замечаю, что основной причиной этой проблемы, по-видимому, было это другое исправление , charset=utf8 которое интерпретировалось как «UTF-8 с BOM». Изменение этой интерпретации на «без спецификации» привело к повреждению некоторых файлов UTF-8, в которых была спецификация. Поэтому, если вы столкнулись с этой проблемой, и исправление Visual Studio еще не выпущено, попробуйте удалить спецификацию из начала текстовых файлов, и это может решить проблему. (Этот комментарий просит ссылки на Zero Wing . :-))
Это было проблемой и для меня. В настоящее время это не исправлено или, по крайней мере, еще не выпущено, или ошибка была вновь введена (версия 15.4.2)
Это часто случается также в том случае, если вы используете в файле ссылки на двоичные файлы (вместо ссылок проекта на код в вашем проекте), а скомпилированный двоичный файл, на который вы ссылаетесь, не синхронизируется с соответствующим исходным кодом на вашем компьютере. Это может произойти из-за того, что вы загрузили новую версию бинарного кода из системы управления исходным кодом без нового исходного кода, который шел с ним, или у вас есть несколько версий бинарного файла на вашей машине, и вы ссылаетесь на старую копию и т. Д. Если это действительно так проблема, это хорошая причина, чтобы использовать ссылки на проекты настолько, насколько это практически возможно.
Я понимаю, что вы имеете в виду, и об этом стоит помнить в будущем, но рассматриваемый источник здесь - проект веб-сайта, а не библиотека классов.
Это распространенная проблема при подборе устаревшего кода, из-за которой я ломаю голову над вопросом, какой гений решил ссылаться на dll из проекта в решении, которое когда-либо использовалось только другим проектом в решении. вздох
Для меня ни один из пунктов не решил проблему. Я просто добавил новую строку кода внутри этой функции, что-то вроде:
добавив, что, я думаю, я вызвал Visual Studio, чтобы добавить эту функцию в исходную версию
Это может произойти, когда системное время изменяется во время отладки или между сеансами отладки, будь то программно, вручную или с помощью внешней программы.
Я не могу +1 этого достаточно. Я недавно переустановил Windows и не заметил, что мои системные часы были выключены. Конечно, это изменение все испортило, и перестройка всего решения / проекта волшебным образом исправила это.
Существует почти незаметная настройка, которая исправила эту проблему для меня. Если есть конкретный исходный файл, в который не попадает точка останова, он может быть указан в
- Обозреватель решений
- щелкните правой кнопкой мыши Решение
- свойства
- Общие свойства
- Отладка исходных файлов
- Msgstr "Не ищите эти исходные файлы".
По какой-то неизвестной мне причине VS 2013 решил разместить там исходный файл, и впоследствии я больше не мог достичь точки останова в этом файле. Это может быть причиной "исходный код отличается от оригинальной версии".
Проблема в том, что ваша информация отладки не синхронизирована с вашей сборкой. Решение простое:
- Перейдите в папку «bin»
- Удалите файлы .pdb
- перестраивать
Должен сделать свое дело!
(Странно то, что перестройка без выбрасывания файлов .pdb не всегда работает. Я вижу, как обновляется дата изменения, но все еще где-то в цепочке (отладчик VS2013, IIS, кэш сборок) это изменение не обнаружено )
После огромной потери времени, потерянного из-за этой проблемы, это решение пошло на пользу. Thx FrankyHollywood
Точка останова будет устранена, как только активатор загрузит сборку (при условии, что символы сборки и отладки обновлены). Хорошее место для просмотра - окно модулей в меню отладки. Там вы должны искать сборку, к которой принадлежит и ваш файл. Сначала убедитесь, что сборка загружена. Тогда откуда он загружается? Затем загружается файл символов. Опять же, откуда загружается файл символов? Наконец, проверьте версии обоих.
Я тоже с этим столкнулся. Условия, которые вызвали мою проблему:
- Я запускаю полный экземпляр IIS7 локально
- Я делаю версию своего программного обеспечения в отдельных проектах
Я вызвал это, открыв предыдущую версию (VS попросил спросить, хочу ли я указать на этот экземпляр в отладке IIS, я ответил «Да»), а затем открыл текущую версию (снова отвечая на приглашение IIS «Да»). ), затем пытается выполнить отладку в предыдущей версии.
Чтобы решить эту проблему, я просто закрыл и заново открыл предыдущую и предполагаемую версию, снова заявив, что это источник отладки.
Попробуйте отключить и заново установить точку останова во время работы в режиме отладки вместо того, чтобы делать это перед запуском режима отладки.
Решение состоит в том, чтобы добавить свойство конфигурации поддержки CLR в запускаемый проект и перекомпилировать его.
Если в вашем решении более одного проекта , убедитесь, что в качестве правильного проекта выбран StartUp Project . Чтобы установить конкретный проект в качестве проекта запуска вашего решения, щелкните проект правой кнопкой мыши и выберите Set As StartUp Project .
После того, как я правильно установил мой StartUp Project, поток достиг желаемой точки останова.
Стоит также отметить, что если ваша точка останова находится в проекте, который НЕ является вашим стартовым проектом, и она НЕ МОЖЕТ стать вашим стартовым проектом (поскольку, например, вам нужен другой проект, который будет стартапом), вы можете (после запуска основного) щелкните правой кнопкой мыши и выберите « Отладка» >> «Начать новый экземпляр проекта», в котором есть точка останова, в которую вы хотите попасть
Я испытал это в 32-битной сборке на vs2017.
Точно ни одно из решений не сработало для меня. Я перезапустил, я очистил файлы IDE, очистил построенное решение, вытащил из git repo и перестроил решение безрезультатно.
Я вытягивал 64-битную зависимость из nuget, и как только я использовал сборку, исходные коды больше не встраивались в конечный исполняемый файл, а вместо этого создавались кэшированные источники IDE.
Я удалил конфигурацию nuget, удалил указанную сборку, загрузил исходный код, собрал log4net вручную, подписал его, добавил его в папку в моем проекте, добавил ссылку на него, и я смог снова выполнить отладку.
Редактировать: во время сборки не было ошибок, несмотря на то, что в настройках IDE была включена опция «запросить ошибку при сборке».
Несмотря на то, что ничего не было выделено, в моем браузере проект работал нормально. Поэтому я решил запустить отладчик, чтобы убедиться, что все работает так, как должно быть.
Я очистил решение и несколько раз перестроил его, удалил tmp файлы, следуя всем направлениям Получение "Исходный файл отличается от того, когда был построен модуль." , перезапустил веб-сервер, и все же он говорит мне, что исходные файлы отличаются, когда они явно не являются.
Я не могу проверить какой-либо из кода, который я написал сегодня из-за этого.
- Как источник может отличаться от двоичного, когда я просто выполнял Это?
- Есть ли способ сбить какой-то смысл в визуальную студию или Я что-то пропустил?
ОТВЕТЫ
Ответ 1
У меня возникла проблема с консольным приложением, где источник, который был другим, был источником, который имел точку входа (static void Main). Удаление каталогов bin и obj и полная перестройка, похоже, исправили это, но каждый раз, когда я делал изменение кода, он снова устарел.
Я нашел для этого следующее:
- Я проверил "Только создавать проекты запуска и зависимости от Run" (Инструменты → Параметры → Проекты и решения → Сборка и запуск)
- В Configuration Manager у моего проекта запуска не было отмечено "Build"
Ответ 2
У меня была такая же проблема, мои проекты были в одном решении, поэтому они использовали ссылки Project to Project, так как одна из них изменилась, остальные должны были быть обновлены. Однако это было не так, я попытался построить, перестроить, закрыть VS2010, вытащил новую копию из нашего источника управления. Ничего из этого не получилось, что я, наконец, пытался попробовать, это щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект по отдельности. Это обновило файлы .dlls и .pdb, чтобы я мог отлаживать.
Проблема здесь в том, что ваши dll и ваши файлы pdb не синхронизированы.
Ответ 3
Выполните следующие действия.
- Просто удалите каталог bin из проекта, в котором создается DLL.
- Восстановите проект.
- Удалить ссылку из проекта, ссылающегося на DLL.
- Включить снова ссылку.
- Наслаждайтесь.
Ответ 4
Некоторые вещи для вас, чтобы проверить:
Вы дважды проверили ссылки на проекты?
У вас есть запущенный веб-сервер Visual Studio, который еще работает? Проверьте системный трей и найдите страницу со значком шестеренки (у вас может быть несколько):
Щелкните правой кнопкой мыши и закройте/выйдите из него. Вы можете иметь более одного. Можете ли вы отладить свои изменения сейчас?
Вы используете отладочную версию, но создали только версию выпуска (или наоборот)?Ответ 5
В дополнение к этим ответам у меня возникла та же проблема при замене новых библиотек DLL на старые из-за неправильного пути. Если вы все еще получаете эту ошибку, вы можете не указывать неправильный путь для DLL. Перейдите в диспетчер IIS и щелкните веб-сайт, который использует ваши библиотеки DLL. В правом окне щелкните "Дополнительные параметры" и перейдите к пути к папке "Физический путь" в проводнике файлов и убедитесь, что вы используете эту папку для замены своих библиотек DLL.
Ответ 6
С помощью веб-служб проблема может быть вызвана использованием команды Visual Studio "Просмотр в браузере". Это помещает файлы DLL службы и PDB в папки bin и obj. При входе в веб-службу от клиента, как-то Visual Studio использует PDB в папке bin (или obj), но использует DLL в папке вывода вывода проекта. Есть несколько способов:
- Попробуйте удалить файлы DLL и PDB в корзине веб-сервиса и файлах obj.
- Попробуйте нажать "Просмотр в браузере" в Visual Studio.
Если вы ранее получили ошибку несоответствия исходного файла, Visual Studio, возможно, добавила имя файла в черный список. Проверьте свойства решения. Выберите "Общие свойства → Отладка исходных файлов" в левой части диалогового окна. Если исходные файлы веб-службы отображаются в поле "Не искать эти исходные файлы", удалите их.
Ответ 7
У меня была эта проблема.
Я пробовал все выше, но только это сработало:
- удалите файл .pdb для решения.
- удалить оскорбительные файлы .obj(для файла, который не синхронизирован)
Это фиксировало проблему для всех движений для меня.
Ответ 8
Вот как я исправил проблему в Visual Studio 2010:
1) Измените параметр "Конфигурации решений" с "Отладка" на "Отпустить"
2) Начать отладку
3) Остановить отладку и переключить опцию "Конфигурации решений" обратно в "Отладка"
Это сработало для меня. Шаг 3 является необязательным - он отлично работал, когда я изменил его на "Release", но я хотел его изменить.
Ответ 9
Я включил существующий проект из другого решения в новый файл решения.
Я не заметил, что когда существующий проект был перестроен, он помещал окончательный вывод в выходной каталог NEW. У меня был путь компоновщика, определенный для поиска в каталоге вывода OLD.
Переключение моего проекта на поиск в выходном каталоге нового решения устраняет эту проблему для меня.
Ответ 10
У меня была эта проблема, и оказалось, что я запускаю консольное приложение в качестве приложения Windows. Исправлена проблема переключения типа вывода на консоль.
Ответ 11
Ответ 12
Выгрузите проект с файлом, который вызывает ошибку.
Ответ 13
В Visual Studio 2017 удаление скрытой папки .vs в разрешенной для меня проблеме.
Ответ 14
Моя проблема заключалась в том, что у меня было два проекта в моем решении. Второй был тестовый проект, используемый для вызова первого. Я выбрал путь к ссылкам из папки выпуска папки bin.
Поэтому всякий раз, когда я вносил изменения в первый код проекта и перестраивал его, он обновлял dll в папке отладки, но вызывающий проект указывал на папку релиза, сообщая мне об ошибке: "исходный файл отличается от того, когда модуль был построен."
Как только я удалил ссылку на основной dll проекта в папке релиза и установил ее в dll в папке отладки, проблема исчезла.
Ответ 15
решение: - проблема в:- если ваши некоторые проекты в решении, обратитесь к некоторым другим проектам, то иногда dll некоторых проектов, не будет обновляться автоматически, всякий раз, когда вы строите решение, некоторые проекты будут иметь предыдущие DLL сборки, а не последние dll
вам нужно перейти вручную и скопировать dll проекта последней сборки в проект, на который ссылается
Ответ 16
Я использовал Visual Studio 2013, и у меня был существующий проект под контролем источника.
Я загрузил новую копию из исходного элемента управления в новый каталог.
После внесения изменений в новую копию, при создании я получил ошибку.Мое решение:
1) Открыть Documents\IISExpress\config\applicationhost.config
2) Обновите virtualDirectory node с помощью каталога в новую копию и сохраните.Ответ 17
Моя проблема заключалась в том, что у меня был веб-сервис в проекте, и я изменил путь сборки.
Восстановление пути сборки по умолчанию разрешило мою проблему.
Ответ 18
У меня была такая же проблема, и я следил за большинством рекомендаций в других ответах, размещенных здесь, для меня ничего не работало.
В итоге я открыл IIS и переработал пул приложений для своего веб-приложения. У меня есть версия IIS 8.5.9600, я щелкнул правой кнопкой мыши мое веб-приложение, а затем: Deploy > Recycle > Recycle pool pool > OK.
Кажется, что он исправил это, точки останова теперь попадают, как ожидалось. Я думаю, что делать это вместе с удалением папок bin и obj помогло мне в этом.
Ответ 19
Я знаю, что это старый вопрос, но у меня была такая же проблема, и я хотел опубликовать здесь, если это поможет кому-то другому. У меня появился новый компьютер, и ИТ-отдел объединил мой старый компьютер с новым. Когда я настраивал TFS, я сопоставил другой локальный путь, чем тот, который я использовал ранее, на дополнительный внутренний диск. Старый путь все еще существовал из объединенных данных на моем жестком диске, поэтому я все еще мог создавать и запускать. Мои пути IIS также указывали на старый каталог. Как только я обновил IIS до правильного пути, я смог отлаживать все отлично. Я также удалил старый каталог для хорошей меры.
Ответ 20
Я также испытал это. Я просто открываю папку obj в проекте, а затем открываю папку отладки, удаляю файл .pdb и все это.
Ответ 21
Эта ошибка также возникает, если вы пытаетесь внести изменения в исходный файл, который не является частью проекта.
Я отлаживал метод из .dll другого одного из моих проектов, где Visual Studio довольно хорошо загрузил источник, потому что DLL был построен на той же машине, и он знал путь к источнику. Очевидно, что изменение такого файла ничего не сделает, если вы не восстановите ссылочный проект.
Ответ 22
- Удалить все точки останова.
- Перестроить.
- Готово
Ответ 23
В Visual Studio 2015 с использованием С++ для меня проблема the source file is different from when the module was built заключалась в
Ответ 24
Отладка- > запуск без отладки.
Этот вариант работал у меня. Надеюсь, это поможет!
Ответ 25
Проверьте правильность местоположения, на которое вы указали, используя mex() в Matlab (содержит файлы lib и obj, которые были изменены до последней даты, когда вы скомпилировали библиотеку в Visual studio).
Если это не так:
Убедитесь, что вы компилируете Visual studio в режиме, который сохраняет файлы .lib:
свойства → свойства конфигурации → общие сведения → тип конфигурации → статическая библиотека
Свойства → Свойства конфигурации → Общие → Целевое расширение =.lib (вместо exe)
Убедитесь, что выходные и промежуточные каталоги соответствуют каталогу Matlab в
- свойства → свойства конфигурации → общие → выходной каталог
- свойства → Свойства конфигурации → Общие → Промежуточный каталог
Ответ 26
В моем случае ответ @Eliott не работает. Для решения этой проблемы мне пришлось исключить/включить из проекта мой дефектный файл, а также очистить и перестроить решение.
После этих действий мой файл с моими последними изменениями и отладчиком восстанавливаются.
Я надеюсь, что это поможет.
Ответ 27
Я получаю эту проблему при отладке иногда с Visual Studio, но когда приложение обслуживается IIS. (Мы должны разрабатывать в этой форме по некоторым сложным причинам, связанным с тем, как первоначальный разработчик настроил этот проект.)
Когда я изменяю файл и перестраиваюсь, это часто исправляет его. Я знаю, что это звучит глупо, но я просто пытался отладить некоторый код, чтобы понять, почему он делает что-то странное, когда я не менял его в течение некоторого времени, и я пробовал дюжину вещей с этой страницы, но это было исправлено, просто изменив файл..
Ответ 28
У меня такая же проблема, и я решаю ее, перестроив все эталонные проекты.
Читайте также:
- Отладка исходных файлов
- Общие свойства
- свойства
- щелкните правой кнопкой мыши Решение
- Построить и запустить
- Проекты и Решения
- Опции