Почему при компиляции проекта C ++ в Visual Studio возникает фатальная ошибка «LNK1104: невозможно открыть файл« C: Program.obj »»?

Это может произойти, если файл все еще работает.

: — 1: ошибка: LNK1104: невозможно открыть файл ‘debug ****. exe’

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

Это было в VS 2013 Ultimate, Windows 8.1.

Также убедитесь, что у вас не включено: Свойства конфигурации -> C/C ++ -> Препроцессор — > Предварительная обработка в файл .

У меня было та же проблема. Она вызвана «,» в имени папки пути дополнительной библиотеки. Решена изменением пути к дополнительной библиотеке.

Моя проблема заключалась в отсутствии .lib extension, я просто ссылался на mylib , и VS решила искать mylib.obj .

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

Решение 1 (для моего случая): перезапустите процесс Windows Explorer (да, файловый менеджер Windows).

Решение 2:

1. Закройте Visual Studio. Выход из Windows
2. Войдите в систему, снова откройте Visual Studio.
3. Выполните сборку как обычно. Теперь он строится и может получить доступ к проблемному файлу.

Я предполагаю, что иногда файловая система или кто-либо, кто ее контролирует, теряются со своими разрешениями. Перед перезапуском сеанса Windows пытался убить процессы зомби msbuild32.exe , перезапустить Visual Studio, не проверять, даже показывая проблемный файл. Нет проблем с конфигурацией сборки. Это случается время от времени. Что-то внутреннее в Windows не исправляется, требуется перезагрузка.

У меня была такая же ошибка, только с пакетом Nuget, который я установил (тот, который не является только заголовком), а затем попытался удалить.
Что было не так для меня, так это что я все еще включал заголовок для пакета, который я только что удалил в одном из моих файлов .cpp (довольно глупо, да).
Я даже удалил ссылки на дополнительные каталоги библиотек в Project - > Свойства -> Компоновщик -> Общие , но, конечно, безрезультатно, поскольку я все еще пытался сослаться на несуществующий заголовок.

В этом случае однозначно запутанное сообщение об ошибке, поскольку имя заголовка было , но ошибка дала мне " невозможно открыть файл 'llibboost_filesystem-vc140-mt-gd-1_59.lib' " и нет номеров строк или чего-то еще.

У меня была та же проблема, но решение для моего случая не указано в ответах. Моя антивирусная программа (AVG) определила файл MyProg.exe как вирус и поместите его в «хранилище вирусов». Вам нужно проверить это хранилище, и если файл там — то просто восстановите его. Мне это помогло.

Для проекта сборки (ProjectName -> Зависимости сборки -> Настройки сборки -> masm (выбрано)), установка для Генерировать предварительно обработанный исходный лист на True тоже вызвала проблему для меня, очистив настройку исправлено Это. VS2013 здесь.

У меня та же проблема с компоновщиком, жалующимся на основной исполняемый файл отсутствует. Это произошло во время переноса нашего решения на новую Visual Studio 2013 . Решение представляет собой разнообразное сочетание управляемых и неуправляемых проектов/кода. Проблема (и исправление) заключалась в том, что в папке решения отсутствовал файл app.config . Потребовался день, чтобы понять это :(, поскольку выходной журнал не очень помог.

Я проверил все свои настройки по этому списку: http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback. Это полезно для меня, и в моей ситуации я обнаружил, что Link Dependency для свойств проектов имеет двойные кавычки, которых не должно быть.

Я отвечаю, потому что не вижу этого конкретного решения перечислен кем-либо еще.

Очевидно, мой антивирус (Ad-Aware) отмечал DLL, от которой зависит один из моих проектов, и удалял ее. Даже после исключения каталога, в котором находится DLL, такое же поведение продолжалось до тех пор, пока я не перезапустил свой компьютер.

В моем случае я заменил файлы математической библиотеки из предыдущего курса Game Engine Graphics на GLM. Проблема заключалась в том, что я не добавил их в проект в обозревателе решений Visual Studio (даже если они были в репозитории проекта).

У меня была эта проблема в связи с ошибкой LNK2038, после этого post, чтобы разделить библиотеки DLL RELEASE и DEBUG. В этом процессе я очистил всю папку, в которой находились эти зависимости.

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

Надеюсь, этот ответ поможет кому-то в нужде.

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

У меня была такая же ошибка:

  фатальная ошибка LNK1104: невозможно открыть файл 'GTest.lib;'  

Это было вызвано ; в конце. Если у вас несколько библиотек, они должны быть разделены пробелом (пробел), без запятой или точкой с запятой!

Поэтому не используйте ; или что-либо еще при перечислении библиотек в Свойства проекта >> Свойства конфигурации >> Компоновщик >> Вход

Я пробовал вышеуказанное решение, но у меня не сработало. Поэтому я переименовал exe и перестроил решение. У меня это работает.

У меня была эта точная ошибка при создании VC ++ DLL в Visual Studio 2019:

LNK1104: невозможно открыть файл ‘C: Program.obj’

Оказалось, что в свойствах проекта> Linker> Input> Module Definition File, я указал файл def, в конце имени которого была двойная кавычка . Удаление несоответствующей двойной кавычки решило проблему.

Убито msbuild32.exe и построен заново. У меня это сработало.

Моя проблема была вызвана другое приложение, использующее файл .dll , который я пытался отлаживать.

Закрытие приложения, которое было с использованием. dll решила эту проблему за меня.

в моем случае это была длина пути (включая имя файла).

  ..  ..  ..  ..  ..  ..  ..  SWX  Binary   VS2008  Output  Win32  Debug  boost_unit_test_framework-vc90-mt-gd-1_57.lib;  

для выпуска путь был (он работал правильно):

  ..  ..  ..  ..  ..  ..  ..  SWX  Binary  VS2008  Output  Win32  Release  boost_unit_test_framework-vc90-mt  -1_57.lib;  

==> на один символ короче.

1. Я также проверил это, переименовав файл lib ( используя короче name) и изменив это в

Linker -> input -> дополнительные зависимости

1. Я также проверил это, добавив абсолютный путь вместо относительного, поскольку все эти «..» также расширили строку пути. это тоже сработало.

, поэтому проблема для меня заключалась в том, что общий размер строки пути + имени файла был слишком длинным!

Я столкнулся с той же проблемой с «Visual Studio 2013».

  LNK1104: невозможно открыть файл 'debug  ****. exe  

Проблема исчезла после закрытия и повторного запуска Visual Studio.