Это сводит меня с ума.
У меня довольно большой проект, который я пытаюсь модифицировать. Ранее я заметил, что, когда я печатал DbCommand
, Visual Studio не выделяла синтаксис, и я использую System.Data.Common
.
Несмотря на то, что ничего не было выделено, казалось, что проект в моем браузере работает нормально. Поэтому я решил запустить отладчик, чтобы проверить, действительно ли все работает так, как должно.
Каждый раз, когда вызывается класс, который не выделил "the source file is different from when the module was built"
текст, я получаю сообщение.
Я очищал решение и перестраивал его несколько раз, удалял файлы tmp, следовал всем указанным здесь инструкциям. Получение «Исходный файл отличается от того, когда был построен модуль». , перезапустил веб-сервер и по-прежнему сообщает мне, что исходные файлы отличаются, хотя это явно не так.
Из-за этого я не могу протестировать какой-либо код, который написал сегодня.
- Как исходный код может отличаться от двоичного, если я только что его выполнил?
- Есть ли способ придать смысл визуальной студии, или я просто чего-то упускаю?
источник
Ответы:
У меня возникла эта проблема при запуске консольного приложения, в котором источник, который отличался, был источником с точкой входа (static void Main). Удаление каталогов bin и obj и выполнение полной перестройки, казалось, исправили это, но каждый раз, когда я вносил изменение в код, он снова становился устаревшим.
Причина, по которой я это нашел:
(Для №2 -> доступно через панель инструментов в раскрывающемся списке «Отладка / Выпуск».)
источник
solution platforms
сAny CPU
наMixed Platform
по ошибке !!! Я снова меняю его на,Any CPU
и он снова работает.У меня была такая же проблема, все мои проекты были в одном решении, поэтому они использовали ссылки Project to Project, так что, если один изменил, другие должны были быть обновлены. Однако это было не так, я попытался собрать, перестроить, закрыть VS2010, вытащил новую копию из нашего источника. Ничего из этого не сработало, в конце концов я попробовал щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект индивидуально. Это обновило файлы .dlls и .pdb, чтобы я мог выполнять отладку.
Проблема здесь в том, что ваши файлы dll и / или pdb не синхронизированы.
источник
Следуй этим шагам
источник
В дополнение к этим ответам у меня была такая же проблема при замене новых DLL на старые из-за неправильного пути. Если вы все еще получаете эту ошибку, вы не можете указать неправильный путь для DLL. Перейдите в диспетчер IIS и щелкните веб-сайт, который использует ваши библиотеки DLL. В правом окне нажмите «Дополнительные параметры» и перейдите к папке «Физический путь» в проводнике и убедитесь, что вы используете эту папку для замены своих DLL.
источник
Некоторые вещи, которые вам стоит проверить:
Вы дважды проверили ссылки на свои проекты?
У вас еще работает запущенный веб-сервер Visual Studio? Проверьте панель задач и найдите страницу со значком шестеренки (у вас может быть несколько):
(источник: msdn.com )
Щелкните правой кнопкой мыши и закройте / выйдите из него. У вас может быть больше одного. Можете ли вы отладить свои изменения сейчас?
Вы используете отладочную версию, но создали только версию выпуска (или наоборот)?Действительно ли компиляция прошла успешно? Я знаю, что нажал на "были ошибки, вы все равно хотите продолжить?" сообщение пару раз, не осознавая.источник
С веб-службами проблема может быть вызвана использованием команды Visual Studio «Просмотр в браузере». Это поместит файлы DLL и PDB службы в папки bin и obj. При входе в веб-службу из клиента Visual Studio каким-то образом использует PDB в папке bin (или obj), но использует DLL в папке выходной сборки проекта. Есть пара обходных путей:
Если вы ранее получали ошибку несоответствия исходного файла, Visual Studio могла добавить имя файла в черный список. Проверьте свойства вашего решения. Выберите «Общие свойства -> Отладка исходных файлов» в левой части диалогового окна. Если исходные файлы вашего веб-сервиса отображаются в поле «Не искать эти исходные файлы», удалите их.
источник
У меня была эта проблема.
Я пробовал все вышеперечисленное, но сработало только это:
построить решение.
Это устранило для меня проблему для всех будущих сборок.
источник
Вот как я исправил проблему в Visual Studio 2010:
1) Измените параметр «Конфигурации решений» с «Отладка» на «Выпуск».
2) Начать отладку
3) Остановите отладку и переключите параметр «Конфигурации решений» обратно на «Отладка».
Это сработало для меня. Шаг 3 не является обязательным - он работал нормально, когда я изменил его на «Release», но я хотел вернуть его обратно.
источник
Мое решение:
Я включил существующий проект из другого решения в новый файл решения.
Я не заметил, что когда существующий проект был перестроен, он помещал окончательный результат в выходной каталог НОВОГО решения. У меня был определен путь компоновщика для просмотра выходного каталога СТАРОГО решения.
Переключение моего проекта на поиск в выходном каталоге нового решения устранило эту проблему для меня.
источник
У меня была эта проблема, и оказалось, что я запускал консольное приложение как приложение Windows. Переключение типа вывода обратно на консоль устранило проблему.
источник
У меня такая же проблема. Чтобы исправить это, я использовал «Release Mode» для отладки в VS2013. Мне этого достаточно, потому что я работаю в аддоне node js \ c ++.
источник
Выгрузите проект, в котором есть файл, вызывающий ошибку.
Перезагрузите проект.
Исправлена
источник
В Visual Studio 2017 удаление скрытой папки .vs решило эту проблему для меня.
источник
Моя проблема заключалась в том, что в моем решении было два проекта. Второй был тестовым проектом, который использовался для вызова первого. Я выбрал путь к ссылкам из папки выпуска папки 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 помогло в моей ситуации.
Удачи!
источник
Я знаю, что это старый вопрос, но у меня была такая же проблема, и я хотел опубликовать здесь, если это поможет кому-то другому. Я получил новый компьютер, и ИТ-отдел объединил мой старый компьютер с новым. Когда я настраивал TFS, я сопоставил локальный путь, отличный от того, который я использовал ранее, на дополнительный внутренний диск. Старый путь все еще существовал из объединенных данных на моем жестком диске, поэтому я все еще мог создавать и запускать. Мои пути IIS также указывали на старый каталог. Как только я обновил IIS до правильного пути, я смог нормально отлаживать. Я также удалил старый каталог на всякий случай.
источник
Я тоже это испытал. Я просто открываю папку 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 . (мы должны развиваться в такой форме по ряду сложных причин, связанных с тем, как исходный разработчик настраивал этот проект.)
Когда я меняю файл и перестраиваю , это часто исправляет. Я знаю, что это звучит глупо, но я просто пытался отладить какой-то код, чтобы понять, почему он делает что-то странное, когда я его давно не менял, и я попробовал дюжину вещей с этой страницы, но это было исправлено, просто изменив файл..
источник