Error — Не создается exe файл в Debug (VS 2020)


Содержание

Visual Studio — не создает исполняемый файл

Я работаю с Visual Studio 2015 для C ++ и создал следующую базовую программу:

Когда я нажимаю CTRL-F5 для запуска программы (или когда я пытаюсь запустить ее в режиме отладки), она генерирует следующую ошибку:

(Обратите внимание, что он успешно собирается, но не может найти файл .exe.) После дальнейшей проверки я обнаружил, что файл .exe не создается.

Мой антивирус не удаляет .exe, и я уверен, что проблема не имеет никакого отношения к PATH. Программа названа правильно с расширением .cpp.

Любые идеи о том, как это исправить?

РЕДАКТИРОВАТЬ:
Я обнаружил, что когда я создаю новый файл C ++ на вкладке «Файл», это приводит к указанной выше ошибке, поскольку файл .cpp не добавляется в проект. Однако, когда вы щелкаете правой кнопкой мыши на боковой панели «Solution Explorer» и создаете там новый файл, добавляется .cpp, и ошибка исчезает. В любом случае, спасибо всем за ответы!

Решение

Вы должны быть в состоянии найти файл .exe в разделе

C: \ Users (имя пользователя) \ Documents \ Visual Studio 2015 \ Projects (имя проекта) \ Debug (имя файла) .exe

Также не запускайте вашу программу в режиме отладки. Запустите его без режима отладки.

Другие решения

У меня была похожая проблема, когда я добавил файл .h через Solution Explorer, а затем переименовал его в файл .cpp и поместил туда свой основной файл. Мне пришлось удалить файл .cpp из проекта, а затем добавить его снова, прежде чем он будет генерировать исполняемый файл.

Ошибка сборки Visual Studio: невозможно скопировать exe-файл из obj\debug в bin\debug

обновление: образец проекта, воспроизводящий эту ошибку, можно найти здесь, в Microsoft Connect. Я также протестировал и проверил, что решение, данное в принятый ответ ниже работает над этим образцом проекта. Если это решение не работает для вас, у вас, вероятно, есть другая проблема (которая относится к отдельному вопросу).

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

сценарий: у меня есть простое приложение Windows Forms (C#, .NET 4.0, Visual Studio 2010). Он имеет несколько базовых форм, которые наследуют большинство других форм, он использует Entity Framework (и классы POCO) для доступа к базе данных. Ничего особенного, нет многопоточности или ничего.

проблема: некоторое время все было в порядке. Затем, все на ровном месте, Visual Studio не удалось построить, когда я собирался запустить приложение. Я получил предупреждение «невозможно удалить файл ‘. bin\Debug\[Имяпроекта].exe. Доступ к пути ‘. bin\Debug\[Имяпроекта].ехе запрещен.» ошибка «невозможно скопировать файл» obj\x86\Debug\[Имяпроекта].exe ‘ to ‘ bin\Debug\[Имяпроекта].exe. Процесс не может получить доступ к файлу » bin\Debug\[ProjectName].exe’, потому что он используется другим процессом.» (я получаю как предупреждение, так и ошибку при запуске Rebuild, но только ошибка при запуске Build — не думаете, что это актуально?)

Я прекрасно понимаю, что говорит предупреждение и сообщение об ошибке: Visual Studio, очевидно, пытается перезаписать exe-файл, в то время как он по какой-то причине заблокирован. Однако это не помогает мне найти решение проблемы. Единственное, что я нашел, это закрыть Visual Studio и запустить его снова. Строительство и запуск тогда работает, пока я не сделаю измените в некоторых формах, тогда у меня снова будет та же проблема и придется перезапустить. Довольно неприятно!

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

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

добавление следующего к следующему в предварительную сборку проекта событие:

добавление в свойства проекта (.файл csproj):

любые предложения высоко ценятся :)

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

Сбой сборки Visual Studio: невозможно скопировать exe-файл из obj\debug в bin\debug

Обновление: пример проекта, воспроизводящего эту ошибку, можно найти здесь, в Microsoft Connect. Я также проверил и подтвердил, что решение, приведенное в принятом ответе ниже, работает с этим примером проекта. Если это решение не работает для вас, возможно, у вас другая проблема (которая относится к отдельному вопросу).

Этот вопрос задавался ранее, как здесь, в Переполнении стека, так и в других местах, но ни одно из предложенных мною предложений не помогло мне, поэтому мне просто нужно попытаться задать новый вопрос.

Сценарий: у меня есть простое приложение Windows Forms (C#, .NET 4.0, Visual Studio 2010). Он имеет несколько базовых форм, от которых наследуется большинство других форм, он использует Entity Framework (и классы POCO) для доступа к базе данных. Ничего особенного, нет многопоточности или чего-то еще.

Проблема: все было хорошо некоторое время. Затем, совершенно неожиданно, Visual Studio не удалось собрать, когда я собирался запустить приложение. Я получил предупреждение «Невозможно удалить файл». bin\Debug\[ProjectName].exe’. Доступ к пути «. bin \ Debug \ [ProjectName].exe’ запрещен». « и ошибка «Невозможно скопировать файл» obj\x86\Debug\[ProjectName].exe «в» bin \ Debug \ [ProjectName].exe «. Процесс не может получить доступ к файлу» bin \ Debug \ [ProjectName].exe » потому что он используется другим процессом. « (Я получаю и предупреждение и ошибку при запуске Rebuild, но только ошибку при запуске Build — не думаю, что это актуально?)

Я прекрасно понимаю, что говорится в предупреждении и сообщении об ошибке: Очевидно, что Visual Studio пытается перезаписать exe-файл, хотя в то же время он по какой-то причине заблокирован. Тем не менее, это не помогает мне найти решение проблемы. Единственное, что я нашел в работе, — это закрыть Visual Studio и запустить его снова. Затем работает сборка и запуск, пока я не внесу изменения в некоторые формы, затем у меня снова возникнет та же проблема, и мне придется перезапустить. Довольно разочаровывает!

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

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

Добавление следующего к следующему к событию перед сборкой проекта:

Добавление следующего к свойствам проекта (файл.csproj):

Тем не менее, ни один из них не работал для меня, так что вы можете понять, почему я начинаю немного расстраиваться. Я не знаю, где еще искать, поэтому я надеюсь, что кому-то есть, что мне дать! Это ошибка в VS, и если да, то есть ли патч? Или я сделал что-то не так, есть ли у меня круговая ссылка или что-то подобное, и если да, то как я могу узнать?

Любые предложения высоко ценятся:)

Обновление: Как упоминалось в комментарии ниже, я также проверил с помощью Process Explorer, что это на самом деле Visual Studio, которая блокирует файл.

Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug

Update: A sample project reproducing this bug can be found here at Microsoft Connect. I have also tested and verified that the solution given in the accepted answer below works on that sample project. If this solution doesn’t work for you, you are probably having a different issue (which belongs in a separate question).


This is a question asked before, both here on Stack Overflow and other places, but none of the suggestions I’ve found this far has helped me, so I just have to try asking a new question.

Scenario: I have a simple Windows Forms application (C#, .NET 4.0, Visual Studio 2010). It has a couple of base forms that most other forms inherit from, it uses Entity Framework (and POCO classes) for database access. Nothing fancy, no multi-threading or anything.

Problem: All was fine for a while. Then, all out of the blue, Visual Studio failed to build when I was about to launch the application. I got the warning «Unable to delete file ‘. bin\Debug\[ProjectName].exe’. Access to the path ‘. bin\Debug\[ProjectName].exe’ is denied.» and the error «Unable to copy file ‘obj\x86\Debug\[ProjectName].exe’ to ‘bin\Debug\[ProjectName].exe’. The process cannot access the file ‘bin\Debug\[ProjectName].exe’ because it is being used by another process.» (I get both the warning and the error when running Rebuild, but only the error when running Build — don’t think that is relevant?)

I understand perfectly fine what the warning and error message says: Visual Studio is obviously trying to overwrite the exe-file while it the same time has a lock on it for some reason. However, this doesn’t help me find a solution to the problem. The only thing I’ve found working is to shut down Visual Studio and start it again. Building and launching then works, untill I make a change in some of the forms, then I have the same problem again and have to restart. Quite frustrating!

As I mentioned above, this seems to be a known problem, so there are lots of suggested solutions. I’ll just list what I’ve already tried here, so people know what to skip:

    Creating a new clean solution and just copy the files from the old solution.

Adding the following to the following to the project’s pre-build event:

Adding the following to the project properties (.csproj file):

However, none of them worked for me, so you can probably see why I’m starting to get a bit frustrated. I don’t know where else to look, so I hope somebody has something to give me! Is this a bug in VS, and if so is there a patch? Or has I done something wrong, do I have a circular reference or similar, and if so how could I find out?

Any suggestions are highly appreciated :)

Update: As mentioned in comment below, I’ve also checked using Process Explorer that it actually is Visual Studio that is locking the file.

Error — Не создается exe файл в Debug (VS 2020)

Только начал обучение С++ по учебнику Страуструпа.
Загрузил Visual Studio

Начал со стандартного «Hello, World!»

Отладка проходит успешно, ошибок нет.

Однако программа не запускается.

Выходят следующие сообщения:

Следующий проект устарел: Hello, World — Debug Win32

Не удается запустить программу: . /HelloWorld.exe
Не удается найти указанный файл

Что я делаю не так?

Система: Wind x64.

Ответы

  • Изменено kosuke904 20 ноября 2013 г. 5:37
  • Помечено в качестве ответа Maksim Marinov Microsoft contingent staff, Moderator 2 декабря 2013 г. 7:42

Все ответы

  • Изменено kosuke904 20 ноября 2013 г. 5:37
  • Помечено в качестве ответа Maksim Marinov Microsoft contingent staff, Moderator 2 декабря 2013 г. 7:42

Здравствуйте, столкнулся с той же проблемой. «Помечено в качестве ответа», но вопрос остался не решенным. Все делаю как написано здесь -> http://msdn.microsoft.com/ru-ru/library/jj620919.aspx#bkmk_createapp . но исполняемый файл не создается!

Так все-таки, в чем проблема?

Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

Как бы все по руководству (кстати в VS 2010 делал тоже самое и без проблем). Создал проект — добавил файл .срр — написал программу — далее Сборка — Собрать решение, сборка проходит без ошибок. Далее Начать отладку или F5 и вот тут ошибка вылетает «Не удается запустить программу . /путь/ . Не удается найти указанный файл»

Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

Вот описание действий с нуля:

Файл — Создать проект — Visual C++ — Проект Win32 — OK
Запускается мастер приложений — Далее — Тип:Приложение Windows, доп.параметры: Пустой проект — Готово
Файл — Создать файл — Файл С++(.срр) — Открыть
Во вкладке «Исходный код2.срр» пишу код:

#include
int main()
<
cout return 0;
>

далее: СБОРКА — Собрать решение — В выводе:

1>—— Сборка начата: проект: Win32Project2, Конфигурация: Debug Win32 ——
========== Сборка: успешно: 1, с ошибками: 0, без изменений: 0, пропущено: 0 ==========


теперь жму F5 или Начать отладку и тут выводится окно с ошибкой:

«Не удается запустить программу . /путь/ .
Не удается найти указанный файл»

Вот теперь все понятно. Вы совершили 2 ошибки.

Первая. Если Вы предполагаете пользоваться средствами ввода-вывода в консольное окно (printf, cout и проч.), следовательно такое окно должно быть создано загрузчиком ОС. Вам нужен не «Проект Win32», а «Консольное приложение Win32», либо выбрать соответствующую радиокнопку там, где ставите галочку «Пустой проект». В противном случае получите ошибку редактора связей.

Вторая ошибка. Файл исходного кода не принадлежит Вашему проекту. В проект файлы добавляются командой меню «Проект — Добавить новый элемент. «. Существующие файлы можно включить в проект командой «Проект — Добавить существующий элемент. «.

Если сообщение помогло Вам, пожалуйста, не забудьте отметить его как ответ данной темы. Удачи в программировании!

Настраиваем удобную сборку проектов в Visual Studio

Эта статья является руководством по настройке сборки C++ проектов Visual Studio. Частично она сводилась из материалов разрозненных статей на эту тему, частично является результатом реверс-инжениринга стандартных конфигурационных файлов Студии. Я написал ее в основном потому что полезность документации от самой Microsoft на эту тему стремится к нулю и мне хотелось иметь под рукой удобный референс к которому в дальнейшем можно будет обращаться и отсылать других разработчиков. Visual Studio имеет удобные и широкие возможности для настройки по-настоящему удобной работы со сложными проектами и мне досадно видеть что из-за отвратительной документации эти возможности очень редко сейчас используются.

В качестве примера попробуем сделать так чтобы в Студию можно было добавлять flatbuffer schema, а Студия автоматически вызывала flatc в тех случаях когда это нужно (и не вызывала — когда изменений не было) и позволяла задавать настройки напрямую через File Properties

Оглавление

ЗАМЕЧАНИЕ: все приведенные в статье примеры проверялись в VS 2020. В рамках моего понимания они должны работать и в более ранних версиях студии начиная по крайней мере с VS 2012, но обещать я этого не могу.

Level 1: лезем внутрь .vcxproj файлов

Давайте взглянем внутрь типичного .vcxproj автоматически сгенеренного Visual Studio.

Довольно нечитаемое месиво, не правда ли? И это ведь еще очень небольшой и практически тривиальный файл. Попробуем превратить его во что-то более читабельное и удобное для восприятия.

Поговорим о .props файлах

Для этого обратим пока внимание на то что взятый нами файл — это обычный XML-документ и его можно логически разделить на две части, в первой из которых перечисляются настройки проекта, а во второй — входящие в него файлы. Давайте эти половинки разделим физически. Для этого нам понадобится уже встречающийся в коде тэг Import который является аналогом сишного #include и позволяет включить один файл в другой. Скопируем наш .vcxproj в какой-нибудь другой файл и уберем из него все объявления относящиеся к файлам входящим в проект, а из .vcxproj-а в свою очередь наоборот уберем все кроме объявлений относящихся к файлам собственно входящим в проект. Получившийся у нас файл с настройками проекта но без файлов в Visual Studio принято называть Property Sheets и сохранять с расширением .props. В свою очередь в .vcxproj мы поставим соответствующий Import

Цукерберг рекомендует:  Кто такой iOS-разработчик

Его можно упростить еще больше, убрав лишние XML-элементы. К примеру свойство «PrecompiledHeader» объявляется сейчас 4 раза для разных вариантов конфигурации (release / debug) и платформы (win32 / x64) но каждый раз это объявление одно и то же. Кроме того у нас здесь используется несколько разных ItemGroup тогда как в реальности вполне достаточно одного элемента. В результате приходим к компактному и понятному .vcxproj который просто перечисляет 1) входящие в проект файлы, 2) то чем является каждый из них (плюс настройки специфичные для конкретных отдельных файлов) и 3) содержит в себе ссылку на хранящиеся отдельно настройки проекта.

Перезагружаем проект в студии, проверяем сборку — все работает.

Но зачем вообще разделять .vcxproj и .props?

Поскольку в сборке ничего не поменялось, то на первый взгляд может показаться что мы поменяли шило на мыло, сделав бессмысленный «рефакторинг» файла в который нам до этого собственно и не было никакой нужды заглядывать. Однако допустим на минутку что в наш solution входит более одного проекта. Тогда, как несложно заметить, несколько разных .vcxproj-файлов от разных проектов могут использовать один и тот же .props файл с настройками. Мы отделили правила сборки используемые в solution от исходного кода и можем теперь менять настройки сборки для всех однотипных проектов в одном месте. В подавляющем большинстве случаев подобная унификация сборки — это хорошая идея. К примеру добавляя в solution новый проект мы в одно действие тривиально перенесем в него подобным образом все настройки из уже существующих в solution проектов.

Но что если нам все же нужны разные настройки для разных проектов? В этом случае мы можем просто создать несколько разных .props-файлов для разных типов проектов. Поскольку .props-файлы могут совершенно аналогичным образом Import-ить другие .props-файлы, то довольно легко и естественно можно выстроить «иерархию» из нескольких .props-файлов, от файлов описывающих общие настройки для всех проектов в solution до узкоспециализированных версий задающих специальные правила для всего одного-двух проектов в solution. В MSBuild действует правило что если одна и та же настройка объявляется во входном файле дважды (скажем вначале импортится в base.props а затем объявляется повторно в derived.props который import-ит в своем начале base.props) то более позднее объявление перекрывает более раннее. Это позволяет легко и удобно задавать произвольные иерархии настроек просто перекрывая в каждом .props файле все необходимые для данного .props-а настройки не заботясь о том что они могли быть где-то уже объявлены ранее. В числе прочего где-нибудь в .props-ах разумно импортировать стандартные настройки окружения Студии которые для C++-проекта будут выгледеть вот так:

Отмечу что на практике весьма удобно класть собственные .props файлы в ту же папку что и .sln файл

Делаем настройку проекта читабельнее

Теперь когда нам больше не требуется возиться с каждым проектом по отдельности мы можем уделить больше внимания настройке процесса сборки. И для начала я рекомендую дать с помощью .props-файлов вменяемые имена большинству интересных объектов в файловой системе относящихся к solution. Для этого нам следует создать тэг PropertyGroup с пометкой UserMacros:

Тогда в настройках проектов вместо конструкций вида «..\..\..\ThirdParty\protobuf\src\protoc.exe» мы сможем написать просто «$(ProtoBufRoot)\protoc.exe». Помимо большей читабельности это делает код намного мобильнее — мы можем свободно перемещать .vcxproj не боясь что у него слетят настройки и можем перемещать (или обновлять) Protobuf изменив всего одну строчку в одном из .props файлов.

При последовательном объявлении нескольких PropertyGroups их содержимое будет объединено — перезапишутся только макросы имена которых совпадают с ранее объявлявшимися. Это позволяет легко дополнять объявления во вложенных .props файлах не боясь потерять макросы уже объявленные ранее.

Делаем удобным подключение сторонних библиотек

Обычный процесс включения зависимости от thirdparty-библиотеки в Visual Studio частенько выглядит примерно вот так:

Процесс соответствующей настройки включает в себя редактирование сразу нескольких параметров находящихся на разных вкладках настроек проекта и потому довольно зануден. Вдобавок его обычно приходится проделывать по нескольку раз для каждой отдельно взятой конфигурации в проекте, так что нередко в результате подобных манипуляций оказывается что проект в Release-сборке собирается, а в Debug-сборке — нет. Так что это неудобный и ненадежный подход. Но как Вы наверное уже догадываетесь, те же самые настройки можно «упаковать» в props-файл. К примеру для библиотеки ZeroMQ подобный файл может выглядеть примерно так:

Обратите внимание что если мы просто определим тэг типа AdditionalLibraryDirectories в props-файле, то он перекроет все более ранние определения. Поэтому здесь используется чуть более сложная конструкция в которой тэг завершается последовательностью символов ;%(AdditionalLibraryDirectories) образующих ссылку тэга самого на себя. В семантике MSBuild этот макрос раскрывается в предыдущее значение тэга, так что подобная конструкция дописывает параметры в начало строки хранящейся в парамере AdditionalLibraryDirectories.

Для подключения ZeroMQ теперь достаточно просто импортировать данный .props файл.

И на этом манипуляции с проектом заканчиваются — MSBuild автоматически подключит необходимые заголовочные файлы и библиотеки и в Release и в Debug сборках. Таким образом потратив немного времени на написание zeromq.props мы получаем возможность надежно и безошибочно подключать ZeroMQ к любому проекту всего в одну строчку. Создатели Студии даже предусмотрели для этого специальный GUI который называется Property Manager, так что любители мышки могут проделать ту же операцию в несколько кликов.

Правда как и остальные инструменты Студии этот GUI вместо читабельного однострочника добавит в код .vcxproj что-то вроде

Так что я предпочитаю добавлять ссылки на сторонние библиотеки в .vcxproj файлы вручную.

Аналогично тому что уже обсуждалось ранее, работа с ThirdParty-компонентами через .props файлы позволяет так же легко в дальнейшем обновлять используемые библиотеки. Достаточно отредактировать единственный файл zeromq.props — и сборка всего solution синхронно переключится на новую версию. К примеру в наших проектах сборка проекта через этот механизм увязана с менеджером зависимостей Conan который собирает необходимый набор thirdparty-библиотек по манифесту зависимостей и автоматически генерирует соответствующие .props-файлы.

Project Templates — автоматизируем создание проектов

Править вручную .vcxproj-файлы созданные Студией конечно довольно скучно (хотя при наличии навыка и недолго). Поэтому в Студии предусмотрена удобная возможность по созданию собственных шаблонов для новых проектов, которые позволяют провести ручную работу по настройке .vcxproj лишь один раз, после чего повторно использовать ее одним кликом в любом новом проекте. В простейшем случае для этого даже не надо ничего править вручную — достаточно открыть проект который нужно превратить в шаблон и выбрать в меню Project \ Export Template. В открывшемся диалоговом окне можно задать несколько тривиальных параметров вроде имени для шаблона или строки которая будет показываться в его описании, а так же выбрать, будет ли вновь созданный шаблон сразу добавлен в диалоговое окно «New Project». Созданный таким способом шаблон создает копию использованного для его создания проекта (включая все файлы входящие в проект), заменяя в нем только имя проекта и его GUID. В довольно большом проценте случаев этого более чем достаточно.

При более детальном рассмотрении сгенерированного Студией шаблона можно легко убедиться в том что это просто zip архив в котором лежат все файлы использованные в шаблоне и один дополнительный конфигурационный файл с расширением .vstemplate. В этом файле хранится список метаданных проекта (вроде использованной иконки или строки с описанием) и список файлов которые необходимо создать при создании нового проекта. Например,

Обратите внимание на параметр ReplaceParameters=«true». В данном случае он применяется только к vcxproj-файлу который выглядит следующим образом:

На месте GU >
Полученный ZIP-архив с шаблоном можно добавить в список шаблонов известных Студии одним из нескольких способов. Проще всего просто скопировать этот файл в папку %USERPROFILE%\Documents\Visual Studio XX\Templates\ProjectTemplates. Стоит заметить, что несмотря на то что в этой папке Вы найдете множество разных подпапок совпадающих по названиям с папками в окне создания нового проекта, по факту шаблон следует положить просто в корневую папку поскольку положение шаблона в дереве новых проектов определяется Студией из тэгов ProjectType и ProjectSubType в .vstemplate-файле. Этот способ удобнее всего подходит для создания «персональных» шаблонов уникальных только для Вас и если Вы выберете в диалоге Export Template галочку «Automatically import template into Visual Studio» то Студия именно это и сделает, поместив созданный при экспорте zip-архив в эту папку с шаблонами. Однако делиться такими шаблонами с коллегами путем их ручного копирования конечно не очень удобно. Поэтому давайте познакомимся с чуть более продвинутым вариантом — создадим Visual Studio Extension (.vsix)

Для создания VSIX нам понадобится установить опциональный компонент Студии который так и называется — средства для разработки Visual Studio Extensions:

После этого в разделе Visual C# \ Extensibility появится вариант «VSIX project». Обратите внимание, что несмотря на свое расположение (C#), он используется для создания любых расширений, в том числе и наборов шаблонов проектов на C++.


В созданном VSIX проекте можно делать массу самых разных вещей — к примеру, создать свое собственное диалоговое окно которое будет использоваться для настройки создаваемых по шаблону проектов. Но это отдельная огромная тема для обсуждения которую я не буду в этой статье затрагивать. Для создания же шаблонов в VSIX все устроено предельно просто: создаем пустой VSIX проект, открываем файл .vsixmanifest и прямо в GUI задаем все данные для проекта. Вписываем метаданные (название расширения, описание, лицензия) на вкладке Metadata. Обратите внимание на расположенное в правом верхнем углу поле «Version» — его желательно указать правильно, поскольку Студия впоследствии использует именно его для определения того какая версия расширения установлена на компьютере. Затем идем на вкладку Assets и выбираем «Add new Asset», с Type: Microsoft.VisualStudio.ProjectTemplate, Source: File on filesystem, Path: (имя к zip-архиву с шаблоном). Нажимаем OK, повторяем процесс пока не добавим в VSIX все желаемые шаблоны.

После этого остается выбрать Configuration: Release и скомандовать Build Solution. Код писать не требуется, править конфигурационные файлы вручную — тоже. На выходе получается переносимый файл с расширением .vsix, который является, по сути, инсталлятором для созданного нами расширения. Созданный файл будет «запускаться» на любом компьютере с установленной Студией, показывать диалог с описанием расширения и лицензией и предлагать установить его содержимое. Разрешив установку — получаем добавление наших шаблонов в диалоговое окно «Создать новый проект»

Подобный подход позволяет легко унифицировать работу большого количества человек над проектом. Для установки и использования шаблонов от пользователя не требуется никакой квалификации кроме пары кликов мышкой. Установленное расширение можно посмотреть (и удалить) в диалоге Tools \ Extensions and Updates

Level 2: настраиваем кастомную компиляцию

ОК, на этом этапе мы разобрались как организованы vcxproj и props файлы и научились их организовывать. Давайте теперь предположим что мы хотим добавить в наш проект парочку .proto схем для сериализации объектов на основе замечательной библиотеки Google Protocol Buffers. Напомню основную идею этой библиотеки: Вы пишите описание объекта («схему») на специальном платформонезависимом мета-языке (.proto-файл) которая компилируется специальным компилятором (protoc.exe) в набор .cpp / .cs / .py / .java / etc. файлов которые реализуют сериализацию / десериализацию объектов по этой схеме в нужном языке программирования и которые Вы можете использовать в своём проекте. Таким образом при компиляции проекта нам нужно первым делом позвать protoc который создаст для нас набор .cpp файлов которые мы в дальнейшем будем использовать.

Традиционный подход

Классическая реализация «в лоб» прямолинейна и состоит в том чтобы просто добавить вызов protoc в pre-build step для проекта которому нужны .proto-файлы. Примерно вот так:

Но это не очень удобно:

  • Требуется явно указывать список обрабатываемых файлов в команде
  • При изменении этих файлов билд НЕ будет пересобран автоматически
  • При изменении ДРУГИХ файлов в проекте которые Студия распознает как исходные коды, напротив, без нужды будет выполнен pre-build step
  • Сгенерированные файлы не входят по умолчанию в сборку проекта
  • Если мы включим сгенерированные файлы в проект вручную, то проект будет выдавать ошибку когда мы его будем открывать в первый раз (поскольку файлы еще не сгенерированы первой сборкой).

Вместо этого мы попробуем «объяснить» самой Visual Studio (а точнее используемой ею системе сборки MSBuild) то как следует обрабатывать подобные .proto-файлы.

Знакомимся с MSBuild targets

С точки зрения MSBuild, сборка любого проекта состоит из последовательности сборки сущностей которые называются build targets, сокращенно targets. К примеру сборка проекта может включать в себя выполнение таргета Clean который удалит оставшиеся от предыдущих билдов временные файлы, затем выполнение таргета Compile который скомпилирует проект, затем таргета Link и наконец таргета Deploy. Все эти таргеты вместе с правилами по их сборке не фиксированы заранее а определяются в самом .vcxproj файле. Если Вы знакомы с nix-овой утилитой make и Вам на ум в этот момент приходит слово «makefile», то Вы совершенно правы: .vcxproj является XML-вариацией на тему makefile.

Но стоп-стоп-стоп скажет тут сбитый с толку читатель. Как это так? Мы просмотрели до этого .vcxproj в простом проекте и там не было ни target-ов ни какого-либо сходства с классическим makefile. О каких target-ах тогда может идти речь? Оказывается что они просто «спрятаны» вот в этой строчке включающей в .vcxproj набор стандартных target-ов для сборки C++ — кода.

«Стандартный» билд-план предлагаемый Студией довольно обширен и предлагает большой набор правил для компиляции C++-кода и «стандартных» таргетов типа Build, Clean и Rebuild к которым умеет «цепляться» Студия. Этот набор часто известен под собирательным названием toolset и заменяя в импорте toolset можно заставить Студию компилировать один и тот же проект с помощью другой версии Студии или, к примеру, интеловским компилятором или Clang. Кроме того при желании от стандартного toolset-а можно вообще отказаться и написать свой собственный toolset с нуля. Но мы будем рассматривать в этой статье более простой вариант в котором мы ничего не будем заменять, а лишь дополним стандартные правила необходимыми нам дополнениями.

Но вернемся обратно к target-ам. Любой target в MSBuild определяется через

  • Список входов (inputs)
  • Список выходов (outputs)
  • Зависимости от других targets (dependencies)
  • Настройки target-а
  • Последовательность фактических шагов выполняемых target-ом (tasks)

Например таргет ClCompile получает на вход список .cpp файлов в проекте и генерирует из них путем таски вызывающей компилятор cl.exe набор .obj файлов. Настройки таргета ClCompile при этом превращаются в флаги компиляции передаваемые cl.exe. Когда мы пишем в .vcxproj файле строчку

то мы добавляем (Include) файл protobuf_tests.cpp в список входов (inputs) данного таргета, а когда пишем

то присваем значение «Use» настройке ClCompile.PrecompiledHeader которую target затем превратит в флаг /Yu переданный компилятору cl.exe.

Попробуем создать target для сборки .proto файлов

Добавление нового target-а реализуется с помощью тэга target:

Традиционно target-ы выносят в подключаемый файл с расширением .targets. Не то чтобы это было строго необходимо (и vcxproj и targets и props файлы внутри являются равнозначным XML-ем), но это стандартная схема именования и мы будем ее придерживаться. Чтобы в коде .vcxproj файла теперь можно было писать что-то вроде

созданный нами target необходимо добавить в список AvailableItemName

Нам также понадобится описать что же конкретно мы хотим сделать с нашими входными файлами и что должно получиться на выходе. Для этого в MSBuild используется сущность которая называется «task». Таска — это какое-то простое действие которое нужно сделать в ходе сборки проекта. К примеру «создать директорию», «скомпилировать файл», «запустить команду», «скопировать что-то». В нашем случае мы воспользуемся таской Exec чтобы запустить protoc.exe и таской Message чтобы отобразить этот шаг в логе компиляции. Укажем так же что запуск данного target-а следует провести сразу после стандартного таргета PrepareForBuild. В результате у нас получится примерно вот такой файлик protobuf.targets

Мы использовали здесь довольно нетривиальный оператор «%» (batching operator) который означает «для каждого элемента из списка» и автоматически добавляемые метаданные. Идея тут в следующем: когда мы записываем код вида

то мы этой записью добавляем в список с названием «ProtobufSchema» дочерний элемент «test.proto» у которого есть дочерний элемент (метадата) AdditionalData содержащая строку «Test». Если мы напишем «ProtobufSchema.AdditionalData» то мы получим доступ к записи «Test». При этом помимо явно объявленных нами метаданных AdditionalData, хитрый MSBuild ради нашего удобства автоматически добавляет к записи еще добрый десяток полезных часто используемых дочерних элементов описанных вот здесь из числа которых мы использовали Identity (исходная строка), Filename (имя файла без расширения) и FullPath (полный путь к файлу). Запись же со знаком % заставляет MSBuild применить описанную нами операцию к каждому элементу из списка — т.е. к каждому .proto файлу по отдельности.

Цукерберг рекомендует:  Медийная реклама. Adventum. Видеокурс. Основные понятия и принципы планирования медийных рекламных

в protobuf.props, переписываем наши proto-файлы в .vcxproj-е на тэг ProtobufSchema

и проверяем сборку

1>—— Rebuild All started: Project: protobuf_test, Configuration: Debug x64 ——
1>Compiling schema test.proto
1>Compiling schema test2.proto
1>pch.cpp
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Ура! Заработало! Правда наши .proto файлы теперь стали не видны в проекте. Лезем в .vcxproj.filters и вписываем там по аналогии

Перезагружаем проект — файлы снова видны.

Доводим наш модельный пример до ума

Впрочем на самом деле я немного схитрил. Если не создать вручную перед началом билда папку generated, то билд на самом деле падает

1>. \protobuf_test\protobuf.targets(13,6): error MSB3073: The command «. \ThirdParty\protobuf\bin\protoc.exe —cpp_out=.\generated test.proto» exited with code 1.

Чтобы это исправить добавим вспомогательный target который создаст необходимую папку

С помощью свойства DependsOnTargets мы указываем что перед тем как запускать любую из задач GenerateProtobuf следует запустить PrepareToGenerateProtobuf, а запись @(ProtobufSchema) ссылается на список ProtobufSchema целиком, как единую сущность используемую как вход для этой задачи, так что запущена она будет лишь один раз.

Перезапускам сборку — работает! Давайте попробуем сделать теперь еще раз Rebuild, чтобы уж на этот раз точно во всем убедиться

1>—— Rebuild All started: Project: protobuf_test, Configuration: Debug x64 ——
1>pch.cpp
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Эм, а куда же пропали наши новые таски? Небольшая отладка — и мы видим что таски на самом деле запускаются MSBuild, но не выполняются поскольку в указанной нами выходной папке уже есть сгенерированные файлы. Проще говоря в Rebuild у нас не работает Clean для .\generated файлов. Исправим это, добавив еще один таргет

Проверяем — работает. Clean очищает созданные нами файлы, Rebuild пересоздает их заново, повторный вызов Build не запускает без нужды пересборку еще раз.

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Вносим правку в один из C++ файлов, пробуем сделать Build еще раз

1>—— Build started: Project: protobuf_test, Configuration: Debug x64 ——
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

.proto-файл не менялся, поэтому protoc не перезапускался, все ожидаемо. Пробуем теперь изменить .proto файл.

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========


Интересно что если запустить сборку MSBuild через командную строку вручную, а не через UI из Студии то такой проблемы не будет — MSBuild корректно пересоберет необходимые .pp.cc файлы. Если мы поменяем какой-нибудь .cpp то запустившийся в студии MSBuild пересоберет не только его, но и .props файл который мы меняли раньше

1>—— Build started: Project: protobuf_test, Configuration: Debug x64 ——
1>Compiling schema test.proto
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

U2DCheck и tlog файлы

Оказывается что создатели Visual Studio посчитали что вызывать MSBuild на каждый чих слишком накладно и… реализовали собственную «быструю проверку» на то нужно ли собирать проект или нет. Она называется U2DCheck и если по ее мнению проект не менялся, то Студия просто не станет запускать MSBuild для этого проекта. Обычно U2DCheck работает настолько «тихо» что про ее существование мало кто догадывается но в реестре можно включить полезный флажок который заставит U2DCheck выводить более подробные отчеты.

В своей работе U2DCheck опирается на специальные .tlog файлы. Их легко можно найти в intermediate-output папке (имя_проекта).tlog и чтобы U2DCheck корректно реагировал на изменения в исходных файлах нам надо сделать в этой папке запись в один из read tlog — файлов, а чтобы U2DCheck корректно реагировал на удаление выходных файлов — запись в одном из write tlog — файлов.

Чертыхнувшись, возвращаемся к соответствующей правке нашего target-а

Проверяем — работает: правка .props файла триггерит необходимый ребилд, сборка в отсутствие правки показывает что проект up-to-date. В данном примере для простоты я не стал писать write tlog отслеживающий удаление созданных при компиляции файлов, но он добавляется в target аналогичным образом.

Начиная с Visual Studio 2020 update 15.8 в MSBuild была добавлена новая стандартная таска GetOutOfDateItems которая автоматизирует эту черную магию, но поскольку это произошло совсем недавно то практически все кастомные .target-ы продолжают работать с .tlog файлами вручную.

При желании можно так же полностью отключить U2DCheck для любого проекта добавив одну строчку в поле ProjectCapability

Однако в этом случае Студия будет гонять MSBuild для этого проекта и всех зависящих от него при каждой сборке и да, U2DCheck добавляли не просто так — это работает не так быстро как мне хотелось бы.

Финализуем наш кастомный .target

Получившийся у нас результат вполне работоспособен, но его есть еще куда совершенствовать. К примеру в MSBuild существует режим «выборочной сборки» когда в командной строке указывается что требуется собрать не весь проект в целом, а лишь отдельные конкретно выбранные в нем файлы. Поддержка этого режима требует чтобы таргет проверял содержимое списка @(SelectedFiles).

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

Наконец мы все еще не реализовали обещанную в самом начале задумку — автоматическое включение сгенерированных файлов в проект. Мы уже можем #include-ить сгенерированные protobuf-ом заголовочные файлы зная что они будут автоматически созданы до того как дело дойдет до компиляции, но с линковщиком этот номер не проходит :). Поэтому просто дописываем сгенерированные файлы в список ClCompile.

Общие настройки здесь были вынесены в PropertyGroup, а списки входных и выходных файлов заполняет новый target ComputeProtobufInput. Попутно (чтобы продемонстрировать работу со списками выходных файлов) была добавлена генерация кода из схемы для интеграции с python. Запускаем и проверяем что все работает правильно

А что насчет CustomBuildStep?

Надо сказать что разработчики из Майкрософт вполне здраво оценивали что все вышеописанное, хм, несколько нетривиально и плохо задокументировано и попытались облегчить жизнь программистов введя специальный таргет CustomBuildStep. В рамках этой концепции мы должны были бы в настройках файла отметить что наши .props файлы относятся к типу Custom Build Step

Затем следовало бы указать необходимые шаги по сборке во вкладке Custom Build Step

В .vcxproj-е это выглядит примерно вот так

Эта конструкция работает за счет того что введенные таким образом данные подставляются в недрах Microsoft.CppCommon.targets в специальный таргет CustomBuildStep который делает, в общем-то, все то же самое что я описал выше. Но работает все через GUI и не надо задумываться о реализации clean и tlog-ах :). При желании этот механизм вполне можно использовать, но я бы не рекомендовал этого делать в силу следующих соображений:

  • CustomBuildStep может быть только один на весь проект
    • Соответственно так обработать можно лишь 1 тип файлов на весь проект
    • Включать такой step в .props файл используемый для подключения ThirdParty библиотеки нецелесообразно, т.к. разные библиотеки могут его перекрывать друг у друга
  • Если в CustomBuildStep что-то ломается, то разобраться в том что случилось будет еще сложнее чем написать таргет с нуля

Правильное копирование файлов

Очень часто встречающейся разновидностью build target является копирование каких-нибудь файлов из одного места в другое. Например копирование файлов ресурсов в папку с собранным проектом или копирование thirdparty DLL к собранному бинарнику. И очень часто эту операцию реализуют «в лоб» через запуск консольной утилиты xcopy в Post-Build Targets. К примеру,

Так делать не надо по тем же самым причинам по которым не надо пытаться запихивать в Post-build steps другие build targets. Вместо этого мы можем напрямую указать Студии что ей необходимо скопировать тот или иной файл. К примеру если файл напрямую входит в проект, то ему достаточно указать ItemType=Copy

После нажатия кнопки apply появится дополнительная вкладка на которой можно настроить куда и как следует копировать выбранный файл. В коде .vcxproj-файла это будет выглядеть примерно так:

Всё заработает «из коробки», включая правильную поддержку tlog-файлов. Внутри это реализовано по все тому же принципу «специальной стандартной таски для копирования файлов» что и Custom Build Step которую я критиковал буквально в предыдущем разделе, но поскольку копирование файлов — довольно тривиальная операция и мы не переопределяем саму операцию (копирование) а лишь меняем список входных и выходных файлов для нее то работает это неплохо.

Замечу что при формировании списков файлов CopyFilesToFolder можно использовать wildcards. К примеру

Добавление файлов в список CopyFileToFolders — пожалуй самый простой способ реализовать копирование при сборке проекта, в том числе в .props-файлах подключающих thirdparty-библиотеки. Однако если хочется получить больше контроля над происходящим, то еще одним вариантом является добавление в свои build target специализированной таски Copy. К примеру

R сожалению таска Copy не поддерживает wildcards и не заполняет .tlog файлы. При желании это можно реализовать вручную,

Однако работа с стандартным CopyFileToFolders обычно будет намного проще.

Level 3: интегрируемся с GUI от Visual Studio

Все то чем мы до сих пор занимались со стороны может показаться довольно унылой попыткой реализовать в не слишком подходящем для этого инструменте функциональность нормального make. Ручная правка XML-файлов, неочевидные конструкции для решения простых задач, костыльные tlog-файлы… Однако у билд-системы Студии есть и плюсы — к примеру после первоначальной настройки она обеспечивает получившимуся билд-плану неплохой графический интерфейс. Для его реализации используется тэг PropertyPageSchema о котором мы сейчас и поговорим.

Вытаскиваем настройки из недр .vcxproj в Configuration Properties

Давайте попробуем сделать так чтобы мы могли бы редактировать свойство $(ProtobufOutputFolder) из «причесанной реализации protobuf.targets» не вручную в файле, а с комфортом прямо из IDE. Для этого нам потребуется написать специальный XAML-файл с описанием настроек. Открываем текстовый редактор и создаем файл с названием, к примеру, custom_settings.xml

Помимо собственно тэга StringProperty который указывает Студии на существование настройки «ProtobufOutputFolder» с типом String и Subtype=Folder и объясняет то как ее следует показывать в GUI, данный XML-ник указывает что хранить эту информацию следует в project file. Помимо ProjectFile можно использовать еще UserFile — тогда данные будут записаны в отдельный файлик .vcxproj.user который по задумке создателей Студии предназначается для приватных (не сохраняемых в VCS) настроек. Подключаем описанную нами схему к проекту, дописав в наш protobuf.targets тэг PropertyPageSchema

Для того чтобы наши правки вступили в силу перезапускаем Студию, загружаем наш проект, открываем project properties и видим…

Да! Появилась наша страничка с нашей настройкой и ее значение по умолчанию было верно прочитано Студией. Пробуем ее изменить, сохраняем проект, смотрим .vcxproj…

Как можно видеть по традиционному условию Condition, по умолчанию настройки ассоциированы с конкретной конфигурацией билда. Но при желании это можно перекрыть с помощью установки флага DataSource HasConfigurationCondition=«false». Правда в 2020 студии присутствует баг из-за которого настройки проекта могут не показываться если среди них нет хотя бы одной настройки ассоциированной с какой-то конфигурацией. К счастью эта настройка может быть невидимой.


Настроек можно добавлять сколько угодно. Возможные типы включают BoolProperty, StringProperty (с опциональными подтипами «folder» и «file»), StringListProperty, IntProperty, EnumProperty и DynamicEnumProperty причем последний может заполняться на лету из любого списка доступного в .vcxproj. Подробнее об этом можно почитать здесь. Можно так же группировать настройки в разделы. Попробуем к примеру добавить еще одну настройку типа Bool

Редактируем настройку, сохраняем проект — все работает как ожидалось

Объясняем Студии про новые типы файлов

До сих пор чтобы добавить в проект protobuf-файл нам необходимо было вручную прописывать в .vcxproj что это . Это легко исправить дописав к упомянутому выше .xml три тэга

Перезапускаем студию, смотрим свойства у наших .proto файлов

Как легко видеть файлы теперь верно распознаются как «Google Protobuf Schema». К сожалению соответствующий пункт не добавляется автоматически в диалог «Add new item», но если мы добавим в проект уже существующий .proto-файл (контекстное меню проекта \ Add \ Existing item… ) то он распознается и добавится правильно. Кроме того наш новый «тип файлов» можно будет выбрать в выпадающем списке Item type:

Ассоциируем настройки с индивидуальными файлами

Помимо настроек «для проекта в целом» совершенно аналогичным образом можно сделать «настройки для отдельного файла». Достаточно указать в тэге DataSource аттрибут ItemType.

Сохраняем, смотрим содержимое .vcxproj

Все работает как ожидалось.

Level 4: расширяем функциональность MSBuild

У меня никогда не возникало необходимости залезать в процесс сборки настолько глубоко, но раз уж статья так и так получилась немаленькой, то коротенько упомяну о последней возможности для кастомизации: расширение самого MSBuild. Помимо довольно обширной коллекции «стандартных» тасков, в MSBuild таски можно «импортировать» из разных источников с помощью тэга UsingTask. К примеру мы можем написать свое расширение для MSBuild, скомпилировать его в DLL-библиотеку и импортировать как-то вот так:

Именно так реализовано большинство «стандартных» тасков предоставляемых Студией. Но таскать с собою кастомную DLL для сборки по очевидным причинам частенько неудобно. Поэтому в тэге UsingTask поддерживается штука которая называется TaskFactory. TaskFactory можно считать «компилятором для task-ов» — мы передаем ей на вход некий исходный «мета-код», а она по нему генерирует реализующий его объект типа Task. К примеру с помощью CodeTaskFactory можно воткнуть код написанной на C# таски прямо внутрь .props-файла.

Если кто-то подобной функциональностью пользовался — отпишитесь об интересных use-case в комментариях.

На этом всё. Надеюсь что мне удалось показать как при настройке MSBuild работу с крупным проектом в Visual Studio можно сделать простой и удобной. Если Вы соберетесь внедрять у себя что-то из описанного выше, то дам небольшой совет: для отладки .props, .targets и .vcxproj удобно выставить MSBuild «отладочный» уровень логгирования в котором он весьма подробно пошагово расписывает свои действия с входными и выходными файлами

Спасибо всем кто дочитал до конца, надеюсь что получилось интересно :).

Делитесь своими рецептами для msbuild в комментариях — я постараюсь обновлять пост чтобы он служил исчерпывающим гайдом по конфигурированию solution в Студии.

VS2010 C++ F7 не создает исполняемый файл в ‘debug’

0 A. K. [2012-01-31 23:38:00]

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

«невозможно запустить программные проекты \workspls\Debug\workpls.exe». Система не может найти этот файл «

Я уже много читал об этом, и я полагаю, что я должен изменить определенные пути в свойствах Решений, чтобы они соответствовали, так как не существует исполняемого файла, созданного в ‘debug’ или в любом другом месте после создания программы. Но каждый раз, когда я перехожу к свойствам Решений, меня путают и не имеют понятия, что нужно изменить. Был бы признателен, если бы кто-нибудь мог мне помочь.

c++ exe debugging path visual-studio-2010

1 ответ

если на вашем выходе указано «Законченный код генерации», затем посмотрите путь к файлу, где визуальная студия написала exe.

Мои файлы exe записывались относительно решения, а не в различные проекты, где я писал код (как я и ожидал).

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

C ++ — Visual Studio 2010 LNK1104 Linker Error: ‘Не удается открыть файл Debug \ AssemblyInfo.obj’ [.obj файлы не создаются во время компиляции]

После того, как много поисков и голову стукнет, я задаю этот вопрос.

Я начал новое приложение Windows Forms в Visual Studio 2010. Дал ему имя и хранить его в месте. не было добавлено или отредактировано в то же ничего. Нет изменений в свойствах проекта либо.

Вот копия Проводника решений.

Я строй пустой формы, и я получаю следующее сообщение об ошибке.

Цукерберг рекомендует:  Боевая психология для фрилансера

Теперь я проверил каждую чертову страницу , имеющую отношение к ошибке (6 ч. Прибегая к помощи !!) Вот список возможных ошибок , как предложено MSDN. Теперь я новичок в МСВС 10, поэтому я полагаю, что .obj файл не присутствует в Debug Window, но AssemblyInfo.cpp присутствует. Что я должен сделать в настройках проекта , так что .obj компилируется и ошибка исчезнет.

Обновление : Еще нет ответов !! Я поражен тем, как НИКТО получает этот вопрос. Вот что я пытался Су далеко и происходит следующее:

  1. Открыт новый Visual C ++ Windows Forms Application (без изменения!)
  2. Записывать АБСОЛЮТНО НИКАКОЙ КОД.
  3. Компоновка проекта

И эта ошибка возникает.

следующий

  1. Открылся старое решение, где .obj файлы присутствовали.
  2. Сделал восстановление раствора.

То же ошибка. Я смотрю на решение в Windows Explorer. Все .obj файлы исчезли (что должно произойти , как восстановление будет очистить .obj файлов). Но то , что остатки onlt в .log файлы.

Таким образом, я выделил ошибку , что компиляция не происходя , как не создаются файлы компоновщика. В результате ошибки линкера LNK1104 или LNK1181 произойти.


Может кто — нибудь сказать мне , почему эта проблема. Кто-нибудь видел это раньше. Может кто — нибудь обеспечить решение, если это возможно ??

c# form Ошибка сборки Visual Studio: невозможно скопировать exe-файл из obj \ debug в bin \ debug

windows forms c# уроки (24)

Переименование файлов .exe и .pub работало для меня, но действительно утомительно. Я также сталкиваюсь с проблемой, которую я не мог редактировать во время сеанса отладки. Наконец, я перешел на страницу настроек расширенной безопасности:

Я отменю выбор, а затем повторно установите флажок «Включить параметры безопасности ClickOnce». Это было проблемой бесплатно в течение нескольких дней .

Обновление: пример проекта, воспроизводящего эту ошибку, можно найти здесь, в Microsoft Connect . Я также проверил и проверил, что решение, данное в принятом ответе ниже, работает над этим образцовым проектом. Если это решение не работает для вас, возможно, у вас другая проблема (которая принадлежит отдельному вопросу).

Это вопрос, заданный раньше, как здесь, так и в Stack Overflow и в других местах, но ни одно из предложений, которое я нашел за последнее время, не помогло мне, поэтому мне просто нужно задать новый вопрос.

Сценарий: у меня есть простое приложение Windows Forms (C #, .NET 4.0, Visual Studio 2010). Он имеет пару базовых форм, которые наследуют большинство других форм, он использует Entity Framework (и классы POCO) для доступа к базе данных. Ничего необычного, многопоточного или ничего.

Проблема: все было хорошо на некоторое время. Затем, все в синем, Visual Studio не удалось создать, когда я собирался запустить приложение. Я получил предупреждение «Невозможно удалить файл» . bin \ Debug \ [ProjectName] .exe ‘. Доступ к пути «. bin \ Debug \ [ProjectName] .exe» запрещен ». и ошибка «Невозможно скопировать файл» obj \ x86 \ Debug \ [ProjectName] .exe ‘в’ bin \ Debug \ [ProjectName] .exe ‘. Процесс не может получить доступ к файлу’ bin \ Debug \ [ProjectName] .exe «потому что он используется другим процессом». (Я получаю предупреждение и ошибку при запуске Rebuild, но только ошибка при запуске Build — не думаю, что это важно?)

Я прекрасно понимаю, что говорит предупреждение и сообщение об ошибке: Visual Studio явно пытается перезаписать exe-файл, в то время как по какой-то причине у него есть блокировка. Однако это не помогает мне найти решение проблемы . Единственное, что я нашел, это закрыть Visual Studio и запустить ее снова. Построение и запуск затем работ, пока я не вношу изменения в некоторые формы, тогда у меня снова возникает такая же проблема, и я должен перезапустить . Довольно неприятно!

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

    Создание нового чистого решения и просто копирование файлов из старого решения.

Добавление следующего к следующему событию предварительной сборки проекта:

Добавление следующего к свойствам проекта (файл .csproj):

Однако ни один из них не работал для меня, поэтому вы, вероятно, можете понять, почему я начинаю немного расстраиваться. Я не знаю, где еще искать, поэтому я надеюсь, что кто-то мне что-то даст! Это ошибка в VS, и если да, то есть патч? Или я сделал что-то неправильно, у меня есть круговая ссылка или что-то подобное, и если да, то как я могу это узнать?

Любые предложения высоко оценены :)

Обновление. Как упоминалось в комментарии ниже, я также проверил с помощью Process Explorer, что на самом деле это Visual Studio, который блокирует файл.

Я знаю, что это очень старый вопрос, но я недавно испытал ошибку «can not copy from obj to bin» в VS 2012. Каждый раз, когда я пытался перестроить определенный проект, я получил сообщение. Единственным решением было сделать чистую перед каждой перестройкой.

После долгих исследований выяснилось, что в одном из моих файлов у меня был неполный отчет о предупреждении pragma, который не мешал компиляции преуспеть, но каким-то образом путал VS, чтобы сохранить файл (ы) заблокированным.

В моем случае у меня было следующее в верхней части файла:

Вот и все. Наверное, я пытался что-то сделать некоторое время назад, отвлекся и не закончил процесс, но предупреждения VS об этой конкретной линии были потеряны в тасовке. В конце концов я заметил предупреждение, удалил линию и каждый раз перестраивал работы с тех пор.

Это будет звучать глупо, но я пробовал все эти решения, работая VS2010 на Windows 7. Ни один из них не работал, кроме переименования и создания, что было ОЧЕНЬ утомительно, если не сказать больше. В конце концов, я выследил преступника, и мне трудно поверить. Но я использовал следующий код в AssemblyInfo.cs .

Это довольно часто, но по какой-то причине изменение версии на 2.0.0.0 заставило все работать снова. Я не знаю, является ли это особенностью Windows 7 (я использую ее только 3-4 недели), или если она случайна или что-то, но она исправила ее для меня. Я предполагаю, что VS держал дескриптор в каждом файле, который он сгенерировал, поэтому он знал бы, как увеличивать вещи? Я действительно не уверен и никогда раньше не видел этого. Но если кто-то еще там вытаскивает волосы, попробуйте.

Вот еще одна возможность:

После получения этой ошибки в vs2012 / win7 я пошел и попытался удалить файл в каталоге bin, а проводник указал, что файл использовался в XAML UI Designer.

Я закрыл все вкладки, которые я открывал в VS, закрыл VS, затем убедился, что вы убили все процессы MSBuild в taskmanager. Наконец, после перезагрузки VS я смог построить решение.

и еще одна возможная причина:

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

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

EDIT: У меня это случалось несколько раз даже недавно с VS2012, и он исправляет его, как только я устанавливаю порядок сборки в правильные зависимости, убиваю любые процессы msbuild, оставшиеся VS, и перезапускает VS. Я просто убиваю процессы msbuild, но закрытие VS также должно их убить.

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

Чтобы проверить порядок сборки: щелкните правой кнопкой мыши Solution в обозревателе решений и выберите «Project Build Order . » и убедитесь, что зависимости указаны для каждого проекта.

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

ЕСЛИ ВАША ПРОБЛЕМА НЕ РЕШАЕТСЯ:

Ошибка Visual studio:

«Процесс не может получить доступ к файлу« bin \ Debug ** app.exe ** », потому что он используется другим процессом».

Итак, перейдите в диспетчер задач окон (Ctrl + Shift + Esc), найдите свое имя приложения и заставьте его закрыть Endprocces.

Я бы посоветовал загрузить Process Explorer чтобы узнать, какой процесс блокирует файл. Его можно найти по адресу:

Использование Visual Studio Я никогда не мог придумать простой проект для воспроизведения ошибки.

Мое решение состояло в том, чтобы отключить процесс хостинга Visual Studio.

Для тех, кого это касается, я приложил трассировку для обрабатывающего дескриптора:


Это обычно вызвано Avast.

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

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

Я нашел с VS2013, я регулярно получаю эту ошибку. Что-то, что, кажется, работает достаточно хорошо, — это выполнить решение перестройки перед попыткой запустить приложение. Я обнаружил, что иногда работает CLEAN, но решение Rebuild работает более последовательно.

Я столкнулся с такой же ошибкой.

Я решил проблему, удалив все содержимое папок bin всех зависимых проектов / библиотек.

Эта ошибка в основном происходит из-за изменений версии.

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

Но если я удалю файл через TotalCommander, exe-файл фактически будет удален, и я смогу успешно построить проект.

Я использую Windows 7 x64 и общий командный элемент 7.56a 32 бит.

Я нашел одно простое решение, просто отключите службы индексирования Windows для папки проекта и подпапок

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

Проблема была на самом деле из-за сбоя сборки и не давала правильной ошибки. Фактической проблемой был недостаток дизайна:

После изменения области действия «a» вне функции или без использования «a» после Task.Factory.StartNew(); , Я смог снова построить.

Это произошло при использовании VS2012 Update 4 в Windows7x64 sp1.

Сообщение об ошибке:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): ошибка MSB3030: Не удалось скопировать файл «obj \ x86 \ Debug \ xxx.exe», потому что он не был найден ,

Я попробовал все другие предложения в ответах здесь, ни одна из которых не сработала. В конце концов я использовал Process Monitor, чтобы узнать, что мой .exe, который VS2010 не смог построить, был заблокирован системным процессом (P >

Обобщены: если у вас отключена служба Application Experience (как и я), перезапустите ее и запустите. Два года обострения закончились.

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

Отключить «Включить хостинг Visual Studio»

Для меня это вызвано открытием командной строки в целевой папке ( C:\users\username\source\repos\project\project\bin\debug\app.publish ).

Не знаю, почему DEBUGGING требует доступа к папке публикации, но закрытие окна команды решило проблему для меня.

Перезапуск IIS- может быть процессом, подключенным к отладчику

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

  • Щелкните правой кнопкой мыши проект, перейдите в «Настройки» и убедитесь, что обе сборки Debug и Release настроены на одни и те же параметры или имеют настройки, которые приложение пытается загрузить или сохранить.
  • Удаление папки C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Убедившись, что файлы, которые у меня были там, считались «заблокированными». Щелкнув правой кнопкой мыши по включенным файлам моего проекта, я понял, что один значок фактически заблокирован и считается плохим, потому что он был загружен из Интернета. Мне пришлось нажать кнопку «Разблокировать» (например, проверьте это: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png — «Этот файл пришел с другого компьютера и может быть заблокирован для помощи защитите этот компьютер. «).

Когда я столкнулся с этой проблемой, это связано с фактом, что проект, который я пытаюсь построить, задан как проект запуска в решении, делающий .exe в заблокированной папке obj (он также появляется в вашем диспетчере задач) щелкните правой кнопкой мыши другой проект в своем решении и выберите «set startup project». Это освободит блокировку, удалит ее из диспетчера задач и позволит вам создавать.

У меня та же проблема (MSB3021) с проектом WPF в VS2008 (в Windows 7 x32). Проблема возникает, если я попытаюсь повторно запустить приложение слишком быстро после предыдущего запуска. Через несколько минут exe-файл разблокируется сам по себе, и я снова могу повторно запустить приложение. Но такая длинная пауза меня злит. Единственное, что действительно помогло мне, — это запустить VS в качестве администратора.

У меня была такая же проблема. Он сказал, что не смог скопировать из bin \ debug в obj .

Когда я создаю веб-проект, я нашел, что моя dll была в папке bin, а не в bin \ debug. Во время публикации vs искал файлы в bin \ debug. Поэтому я открыл файл веб-проекта в редакторе и искал экземпляры bin \ debug, и я нашел, что все dll были упомянуты как bin \ debug \ mylibrary.dll. Я удалил all \ debug из пути и опубликовал его снова. На этот раз vs удалось найти всю dll в папке bin и опубликовать ее успешно.

Я не знаю, как этот путь был изменен в файле веб-проекта.

Я потратил более 5 часов на отладку и наконец нашел решение самостоятельно.

Это правильный ответ .

Это было подано несколько раз на сайте сообществ сообществ сообществ Microsoft. FYI, я считаю, что эта ошибка поразила Visual Studio с 2003 года и исправлена ​​после RTM каждый раз. :( Одна из ссылок следующая:

Ошибка сборки Visual Studio: не удается скопировать exe-файл из obj\debug в bin\debug

обновление:образец проекта, воспроизводящего эту ошибку, можно найти здесь, в Microsoft Connect. Я также протестировал и проверил, что решение, данное в принятый ответ ниже работает над этим образцом проекта. Если это решение не работает для вас, у вас, вероятно, есть другая проблема (которая относится к отдельному вопросу).

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

сценарий: у меня есть простое приложение Windows Forms (C#, .NET 4.0, Visual Studio 2010). Он имеет несколько базовых форм, которые наследуют большинство других форм, он использует Entity Framework (и классы POCO) для доступа к базе данных. Ничего особенного, никакой многопоточности или чего-то еще.

проблема: все было хорошо на некоторое время. Затем, все из ниоткуда, Visual Studio не удалось построить, когда я собирался запустить приложение. Я получил предупреждение «невозможно удалить файл ‘. bin\Debug\[Имяпроекта].exe’. Доступ к пути ‘. bin\Debug\[Имяпроекта].exe ‘ отказано.» ошибка «невозможно скопировать файл’ obj\x86\Debug\[Имяпроекта].exe ‘ to ‘ bin\Debug\[имя проекта].exe’. Процесс не может получить доступ к файлу ‘ bin\Debug\[имя_проекта].exe’, потому что он используется другим процессом.» (я получаю как предупреждение, так и ошибку при запуске Rebuild, но только ошибка при запуске Build — не думаю, что это актуально?)

Я прекрасно понимаю, что говорится в предупреждении и сообщении об ошибке: Visual Studio явно пытается перезаписать exe-файл, в то время как он по какой-то причине заблокирован. Однако это не помогает мне найти решение проблемы. Единственное, что я нашел, это закрыть Visual Studio и запустить его снова. Строительство и запуск затем работает, пока я не сделаю измените некоторые формы, тогда у меня снова будет та же проблема и придется перезапустить. Довольно неприятно!

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

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

добавление следующего к следующему в предварительную сборку проекта событие:

добавление в свойства проекта (.csproj file):

любые предложения высоко ценятся :)

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

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих