Ссылка: неустранимая ошибка LNK1104: не удается открыть файл 'D:...MyProj - ... ехе'

У вас, вероятно, был случайный процесс сборки, который блокировал исполняемый файл, и он (случайный процесс) не очистился. В этом случае закройте visual studio, откройте Process explorer и уничтожьте все процессы, связанные с visual studio. Затем снова откройте visual studio и попробуйте перестроить проект.

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

добавление моего пути проекта к "исключенным элементам" в моих настройках антивируса AVG, похоже, устранило проблему для меня.

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

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

возможно, вы не закрыли выход. Закройте выходные данные, очистите и восстановите файл. Вы сможете запустить файл.

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

проблема заключается в том, что при запуске проекта, а затем получить ошибку, что вы не можете построить свой проект - это так, потому что этот исполняемый файл (ваш проект) по-прежнему выполняется (вы можете проверить его через Диспетчер задач.) Если вы просто переименуете целевую сборку, через некоторое время вы получите ту же ошибку с new имя тоже, и если вы откроете диспетчер задач, вы увидите, что вы мусор системы с вашими не законченными проектами.

Visual studio для создания новой сборки необходимо удалить предыдущий исполняемый файл и создать новый вместо старого, он не может сделать это, пока исполняемый файл все еще выполняется. Итак, если вы хотите сделать новую сборку, процесс старого исполняемого файла должен быть закрыт! (странно, что visual studio не закрывает его сам по себе, и да, это похоже на какую-то багги поведение.)

это утомительно делать вручную, поэтому вы можете просто файл bat и просто щелкнуть по нему, когда у вас есть такая проблема:

taskkill /f /im name_of_target_executable.exe

это работает для меня по крайней мере. Как предположение-я не закрываю свою программу должным образом на C++, поэтому, возможно, для visual studio нормально держать ее запущенной.

дополнение: Существует большой шанс быть таким, из-за не законченного применения. Проверьте, вызывали ли вы PostQuitMessage в конец, для того, чтобы дать знать окна, что вы сделали.

Я пришел к выводу, что это какая-то ошибка Visual Studio. Возможно, C Johnson прав - возможно, процесс сборки держит файл заблокированным.

У меня есть обходной путь, который работает-каждый раз, когда это происходит - я изменяю целевое имя исполняемого файла в свойствах проекта (щелкните правой кнопкой мыши проект, затем Свойства\свойства конфигурации\общее\целевое имя).

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

Если кто-то найдет причину и решение, Пожалуйста, ответьте и я могу двигаться в ответ на ваше, как мое решение.

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

Я хочу поблагодарить user963228, чей ответ действительно является решением этой проблемы. Вы должны поместить Application Experience в ручной запуск(вы можете сделать это, выполнив поиск служб в меню Пуск windows 7, а затем найти Application Experience и нажмите "Свойства").

эта проблема возникает, когда люди хотят tweak theyr windows 7 машина, и они решают отключить некоторые бессмысленные услуги, поэтому они google некоторые настройки руководства и большинство из этих руководств говорят, что опыт применения безопасно отключить.

Я думаю, что эта проблема должна быть связана с проблемой windows 7, а не с проблемой, и она должна быть более заметной - мне потребовалось много времени, чтобы найти это решение.

еще раз спасибо!

чтобы добавить еще одно решение в список, я обнаружил, что Visual Studio (2012 в моем случае) иногда блокирует файлы под разными процессами.

Так, на аварии, команду devenv.exe может по-прежнему работать и удерживать файл(ы). В качестве альтернативы (как я только что обнаружил), vstestrunner или vstestdiscovery также могут удерживать файл.

убейте все эти процессы, и это может решить проблему.

Я только что столкнулся с той же проблемой с VS2013, создавая драйверы устройств на C++ , и ни один из вышеперечисленных, казалось, не исправить проблему. Однако я только что обнаружил, что в моем случае проблема, похоже, связана с VMWare.

я запускал клиент VMWare workstation с общей папкой, определенной на виртуальной машине на всем диске C:. Когда я отключил общие папки в настройках виртуальной машины, VS2013 смог счастливо построить мой .файл EXE.

мой новый процесс есть:

1) Отключите общую папку на виртуальной машине (Настройки | Параметры | общие папки-и снимите флажок) 2) Запустите сборку на хост-ПК 3) повторно включите общую папку (и продолжайте оттуда)

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

(кстати, ошибки, которые вы получаете, это .exe (или другие файлы) заблокированы или требуют разрешения администратора, но это отвлекающий маневр - мне кажется, что общий ресурс VMWare вызывает эти файлы отображаются как заблокированные.)

ошибка возникает (по крайней мере, иногда) из слишком длинных путей. В моем проекте просто сокращение пути к выходному файлу делает работу: "Свойства / Свойства Конфигурации / Общий / Промежуточный Каталог"

кажется, что я попал в ограничение пути 250 символов.

работая с принципами программирования и практикой Bjarne Stroustrup, используя пример c++ "FLTK", я получил ту же ошибку, но через 1 час у меня появилась идея, я отслеживал одну из библиотек, уже виденных в свойствах проекта -> Компоновщик -> ввод -> дополнительные зависимости, в моем случае я отслеживал kernel32.lib, чтобы увидеть, где был расположен и увидел, что было много kernel32.Либ в разных папках. Поэтому я начал копировать библиотеки FLTK в эти папки, и последний, который я пробовал, работал. Visual Studio 2013 Экспресс нашел флткд.Либ и код сработали.

в моем случае правильный маршрут был C:\Program файлы (x86)\Windows Kits\8.1\Lib\winv6.3 \ um\x86

Я не знаю, как установить этот маршрут внутри Visual Studio.

Не уверен, что эта папка Windows kits была создана при установке Microsoft Windows SDK для Windows 7 и .NET Framework 4 (ISO)http://www.microsoft.com/en-us/download/details.aspx?id=8442

надеюсь, что это поможет вам люди.

У меня была та же проблема. Со мной exe все еще работал, но я не мог закончить его с помощью Диспетчера задач. Просто перезапустив VS, это сработало для меня.

мой заключается в том, что если вы установите опцию MASM listing file некоторый дополнительный выбор, это даст вам эту ошибку.

просто использовать

 Enable Assembler Generated Code Listing   Yes/Sg
 Assembled Code Listing $(ProjectName).lst

это нормально.

но любой дополнительный у вас есть проблема.

обычно это означает, что ваша программа заблокирована и не может быть убита через Диспетчер задач или Process explorer. Я встретил аналогичный случай, что моя программа имела исключение во время работы и вызвала отчет об ошибках windows, который заблокировал программу. в случае, если Windows Error reporting блокирует программу, вы можете перейти в Панель управления - >Система и безопасность->Центр действий->настройки отчетов о проблемах, чтобы установить "никогда не проверять решения". надеюсь, что это помогает.