исходный файл отличается от того, когда модуль был собран

103

Это сводит меня с ума.

У меня довольно большой проект, который я пытаюсь модифицировать. Ранее я заметил, что, когда я печатал DbCommand, Visual Studio не выделяла синтаксис, и я использую System.Data.Common.

Несмотря на то, что ничего не было выделено, казалось, что проект в моем браузере работает нормально. Поэтому я решил запустить отладчик, чтобы проверить, действительно ли все работает так, как должно.

Каждый раз, когда вызывается класс, который не выделил "the source file is different from when the module was built"текст, я получаю сообщение.

Я очищал решение и перестраивал его несколько раз, удалял файлы tmp, следовал всем указанным здесь инструкциям. Получение «Исходный файл отличается от того, когда был построен модуль». , перезапустил веб-сервер и по-прежнему сообщает мне, что исходные файлы отличаются, хотя это явно не так.

Из-за этого я не могу протестировать какой-либо код, который написал сегодня.

  • Как исходный код может отличаться от двоичного, если я только что его выполнил?
  • Есть ли способ придать смысл визуальной студии, или я просто чего-то упускаю?
разочарованный кодер
источник
Извините, если это было многовато. Краткая версия: я компилирую свою программу, затем пытаюсь отладить ее, и Visual Studio сообщает мне, что мой исходный файл (который я только что скомпилировал) отличается от модуля, который я только что построил. Я просто хочу знать, почему он так думает
разочарованный

Ответы:

111

У меня возникла эта проблема при запуске консольного приложения, в котором источник, который отличался, был источником с точкой входа (static void Main). Удаление каталогов bin и obj и выполнение полной перестройки, казалось, исправили это, но каждый раз, когда я вносил изменение в код, он снова становился устаревшим.

Причина, по которой я это нашел:

  1. Я проверил «Создавать только запускаемые проекты и зависимости при запуске» (Инструменты -> Параметры -> Проекты и решения -> Сборка и запуск)
  2. В Configuration Manager в моем стартовом проекте не отмечена отметка "Сборка"

(Для №2 -> доступно через панель инструментов в раскрывающемся списке «Отладка / Выпуск».)

Элиотт
источник
7
+1 за подсказку менеджера конфигурации. Я пытался разобраться с этим в течение часа, и все.
Ник Сарабин
У меня было несколько веток решения в TFS. Удаление каталогов bin и obj во всех проверенных ветках, похоже, прояснило ситуацию.
Sparebytes
в моем случае я был изменен solution platformsс Any CPUна Mixed Platformпо ошибке !!! Я снова меняю его на, Any CPUи он снова работает.
vaheeds
Спасибо, Решение> Свойства> Свойства конфигурации> Конфигурация, мое консольное приложение (которое запускает тесты для веб-приложения в том же sln) не было отмечено.
emery.noel
23

У меня была такая же проблема, все мои проекты были в одном решении, поэтому они использовали ссылки Project to Project, так что, если один изменил, другие должны были быть обновлены. Однако это было не так, я попытался собрать, перестроить, закрыть VS2010, вытащил новую копию из нашего источника. Ничего из этого не сработало, в конце концов я попробовал щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект индивидуально. Это обновило файлы .dlls и .pdb, чтобы я мог выполнять отладку.

Проблема здесь в том, что ваши файлы dll и / или pdb не синхронизированы.

Скотт Дин
источник
1
Вы не упомянули прямо, но «выгрузить проект» (перезагрузить снова) у меня работает, спасибо.
javaLover
это сработало для меня:> Ничего из этого не сработало, в конце концов я попробовал щелкнуть правой кнопкой мыши по проекту и перестроить каждый проект индивидуально. Это обновило файлы .dlls и .pdb, чтобы я мог выполнять отладку.
Хачатур
выгрузить проект (перезагрузить снова) и опубликовать последние биты на веб-сервере (IIS) работает для меня.
Джейсон Тан
5

Следуй этим шагам

  1. Просто удалите каталог bin из проекта, в котором создается DLL.
  2. Восстановите проект.
  3. Удалите ссылку из проекта, которая ссылается на DLL.
  4. Включите снова ссылку.
  5. Наслаждаться.
Чарльз
источник
4

В дополнение к этим ответам у меня была такая же проблема при замене новых DLL на старые из-за неправильного пути. Если вы все еще получаете эту ошибку, вы не можете указать неправильный путь для DLL. Перейдите в диспетчер IIS и щелкните веб-сайт, который использует ваши библиотеки DLL. В правом окне нажмите «Дополнительные параметры» и перейдите к папке «Физический путь» в проводнике и убедитесь, что вы используете эту папку для замены своих DLL.

bbciao
источник
4

Некоторые вещи, которые вам стоит проверить:

Вы дважды проверили ссылки на свои проекты?

У вас еще работает запущенный веб-сервер Visual Studio? Проверьте панель задач и найдите страницу со значком шестеренки (у вас может быть несколько):

альтернативный текст
(источник: msdn.com )

Щелкните правой кнопкой мыши и закройте / выйдите из него. У вас может быть больше одного. Можете ли вы отладить свои изменения сейчас?

Вы используете отладочную версию, но создали только версию выпуска (или наоборот)?

Действительно ли компиляция прошла успешно? Я знаю, что нажал на "были ошибки, вы все равно хотите продолжить?" сообщение пару раз, не осознавая.

ChrisF
источник
Компиляция выполняется успешно. Когда дело касается Visual Studio, я немного новичок. Как мне проверить, использую ли я отладочную версию или выпуск?
frustratedcoder
1
@frustrated - я просто пытался избавиться от очевидного. Чтобы проверить, находитесь ли вы в стадии выпуска или отладки, проверьте раскрывающийся список рядом со значком «отладка» на панели инструментов. Это будет либо «Отладка», либо «Выпуск».
ChrisF
Спасибо. Там написано отладка. Так и должно быть?
frustratedcoder
@frustrated - хорошее начало;). Вы можете «отлаживать» код выпуска, но это не так полезно, но здесь это не актуально. Это означает, что вы создаете (или, по крайней мере, должны создавать) и запускаете двоичные файлы отладки. Мне придется подумать еще немного - не видя проблему, ее немного сложно диагностировать.
ChrisF
«не видя на самом деле проблемы, это немного сложно диагностировать», - так я и подумал. Я действительно ценю помощь
разочарованный
3

С веб-службами проблема может быть вызвана использованием команды Visual Studio «Просмотр в браузере». Это поместит файлы DLL и PDB службы в папки bin и obj. При входе в веб-службу из клиента Visual Studio каким-то образом использует PDB в папке bin (или obj), но использует DLL в папке выходной сборки проекта. Есть пара обходных путей:

  1. Попробуйте удалить файлы DLL и PDB в bin и obj файлах веб-службы.
  2. Попробуйте щелкнуть «Просмотр в браузере» в Visual Studio.

Если вы ранее получали ошибку несоответствия исходного файла, Visual Studio могла добавить имя файла в черный список. Проверьте свойства вашего решения. Выберите «Общие свойства -> Отладка исходных файлов» в левой части диалогового окна. Если исходные файлы вашего веб-сервиса отображаются в поле «Не искать эти исходные файлы», удалите их.

user3233739
источник
2

У меня была эта проблема.

Я пробовал все вышеперечисленное, но сработало только это:

  • удалите файл .pdb для решения.
  • удалить оскорбительные файлы .obj (для файла, о котором сообщается, что он не синхронизирован)

построить решение.

Это устранило для меня проблему для всех будущих сборок.

Голлумуллог
источник
Я думаю, что удаление файлов .pdb является ключевым моментом. Это случилось со мной, потому что я скопировал устаревшие файлы .pdb из другой ветки.
Danzomida
1

Вот как я исправил проблему в Visual Studio 2010:

1) Измените параметр «Конфигурации решений» с «Отладка» на «Выпуск».

2) Начать отладку

3) Остановите отладку и переключите параметр «Конфигурации решений» обратно на «Отладка».

Это сработало для меня. Шаг 3 не является обязательным - он работал нормально, когда я изменил его на «Release», но я хотел вернуть его обратно.

djmcghin
источник
1

Мое решение:

Я включил существующий проект из другого решения в новый файл решения.

Я не заметил, что когда существующий проект был перестроен, он помещал окончательный результат в выходной каталог НОВОГО решения. У меня был определен путь компоновщика для просмотра выходного каталога СТАРОГО решения.

Переключение моего проекта на поиск в выходном каталоге нового решения устранило эту проблему для меня.

Бен
источник
1

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

Элиэзер Мирон
источник
1

У меня такая же проблема. Чтобы исправить это, я использовал «Release Mode» для отладки в VS2013. Мне этого достаточно, потому что я работаю в аддоне node js \ c ++.

Jdscardoso
источник
1

Выгрузите проект, в котором есть файл, вызывающий ошибку.

Перезагрузите проект.

Исправлена

Майк
источник
1

В Visual Studio 2017 удаление скрытой папки .vs решило эту проблему для меня.

Джеймс Вестгейт
источник
1

Моя проблема заключалась в том, что в моем решении было два проекта. Второй был тестовым проектом, который использовался для вызова первого. Я выбрал путь к ссылкам из папки выпуска папки bin.

Поэтому всякий раз, когда я вносил изменения в код первого проекта и перестраивал его, он обновлял библиотеки DLL в папке отладки, но вызывающий проект указывал на папку выпуска, давая мне ошибку: «исходный файл отличается от того, когда модуль был построен."

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

Далибор Бьелич
источник
1

В моем случае ответ @Eliott не работает. Чтобы решить эту проблему, я использовал команду «Исключить / включить из проекта» мой несовершенный файл, а также « Очистить и перестроить» решение.

После этих действий мой файл с моими последними изменениями и отладчик восстанавливаются.

Надеюсь, это поможет.

Оби-Ван Кеноби
источник
0

Решение: - проблема в следующем: - если некоторые из ваших проектов в решении, обратитесь к другим проектам, то иногда DLL некоторых проектов не будет обновляться автоматически, всякий раз, когда вы создаете решение, некоторые проекты будут иметь предыдущие сборки DLL, а не последние dll

вам нужно пойти вручную и скопировать dll последнего проекта сборки в указанный проект

user2930560
источник
0

Я использовал Visual Studio 2013, и у меня был существующий проект под контролем версий.
Я загрузил новую копию из системы контроля версий в новый каталог.
После внесения изменений в свежую копию при сборке я получил указанную ошибку.

Мое решение:
1) Откройте Documents\IISExpress\config\applicationhost.config
2) Обновите virtualDirectoryузел с каталогом до новой копии и сохраните.

Th4t парень
источник
0

Моя проблема заключалась в том, что у меня в проекте был веб-сервис, и я изменил путь сборки.

Восстановление пути сборки по умолчанию решило мою проблему.

Boanerge
источник
0

У меня была такая же проблема, и я следовал большинству рекомендаций в других ответах, размещенных здесь, у меня ничего не работало.

В конце концов я открыл IIS и переработал пул приложений для своего веб-приложения. У меня IIS версии 8.5.9600, я щелкнул правой кнопкой мыши свое веб-приложение, затем: «Развернуть»> «Рециркулировать»> «Переработать пул приложений»> «ОК».

Кажется, это исправлено, теперь точки останова достигаются, как и ожидалось. Я думаю, что выполнение этого вместе с удалением папок bin и obj помогло в моей ситуации.

Удачи!

А. Мюррей
источник
0

Я знаю, что это старый вопрос, но у меня была такая же проблема, и я хотел опубликовать здесь, если это поможет кому-то другому. Я получил новый компьютер, и ИТ-отдел объединил мой старый компьютер с новым. Когда я настраивал TFS, я сопоставил локальный путь, отличный от того, который я использовал ранее, на дополнительный внутренний диск. Старый путь все еще существовал из объединенных данных на моем жестком диске, поэтому я все еще мог создавать и запускать. Мои пути IIS также указывали на старый каталог. Как только я обновил IIS до правильного пути, я смог нормально отлаживать. Я также удалил старый каталог на всякий случай.

mslissap
источник
0

Я тоже это испытал. Я просто открываю папку obj в проекте, а затем открываю папку отладки, удаляю файл .pdb и все.

user5912760
источник
0

Эта ошибка также возникает, если вы пытаетесь внести изменения в исходный файл, который не является частью проекта.

Я отлаживал метод из .dll другого из моих проектов, где Visual Studio весьма услужливо загрузила исходный код, потому что .dll была создана на той же машине и ей был известен путь к источнику. Очевидно, что изменение такого файла ничего не даст, если вы не перестроите проект, на который указывает ссылка.

Дэн Бечард
источник
0
  1. Удалите все точки останова.
  2. Восстановить.
  3. Готово
Jaja
источник
0

В Visual Studio 2015 с использованием C ++ the source file is different from when the module was builtпроблема была устранена.

  • перезапустите Visual Studio.
Педро Рейс
источник
0

Отладка-> запуск без отладки.

Этот вариант у меня сработал. Надеюсь это поможет!

Мадхурья Ганди
источник
0

Проверьте правильность местоположения, которое вы указали для использования mex () в Matlab (содержит файлы lib и obj, которые изменены до последней даты, когда вы скомпилировали библиотеку в Visual Studio).

Если это не так:

Убедитесь, что вы компилируете Visual Studio в режиме, сохраняющем файлы .lib:

  1. свойства -> Свойства конфигурации -> Общие -> Тип конфигурации -> статическая библиотека

  2. свойства -> Свойства конфигурации -> Общие -> Целевое расширение = .lib (вместо exe)

Убедитесь, что выходной и промежуточный каталоги соответствуют каталогу Matlab в

  1. свойства -> Свойства конфигурации -> Общие -> Выходной каталог
  2. свойства -> Свойства конфигурации -> Общие -> Промежуточный каталог
Лахмания
источник
0

У меня возникает эта проблема при отладке иногда с Visual Studio, но когда приложение обслуживается IIS . (мы должны развиваться в такой форме по ряду сложных причин, связанных с тем, как исходный разработчик настраивал этот проект.)

Когда я меняю файл и перестраиваю , это часто исправляет. Я знаю, что это звучит глупо, но я просто пытался отладить какой-то код, чтобы понять, почему он делает что-то странное, когда я его давно не менял, и я попробовал дюжину вещей с этой страницы, но это было исправлено, просто изменив файл..

Чейз Андерсон
источник