Проект устарел visual studio 2017
У меня очень похожая проблема, как описано здесь.
даже если он был скомпилирован и связан непосредственно до и Ф5 попал, messagebox " проект устарел. Хотите его построить?" кажется. Это очень раздражает, потому что DLL файл очень низкоуровневый и заставляет практически все проекты решения перестраиваться.
Мои настройки pdb установлены на значение по умолчанию (предлагаемое решение этой проблемы).
возможно ли получить причину, по которой Visual Studio 2010 заставляет перестроить или считает, что проект обновлен?
любые другие идеи, почему Visual Studio 2010 ведет себя так?
только для Visual Studio / Express 2010. См. другие (более простые) ответы для VS2012, VS2013 и т. д.
найти недостающий файл(ы) используйте информацию из статьи включить ведение журнала системы проектов C++ включить ведение журнала отладки в Visual Studio и пусть это просто сказать вам что вызывает перестройку:
-
открыть (находится в %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ или %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ ). Для экспресс-версий файл конфигурации имени V*Express.exe.config .
добавить следующее после </configSections> строку:
поиск в журнале отладки для любых строк формы:
команду devenv.exe информация: 0: проект ' Bla\Bla\Dummy.vcxproj ' не актуален, потому что ввод сборки 'Бла\Бла\Некий-Файл.ч' отсутствует.
(Я просто нажал Ctrl+F и искал not up to date ) это будут ссылки, заставляющие проект постоянно быть "устаревшим".
Примечание: при использовании 2012 или более поздней версии фрагмент должен быть:
в Visual Studio 2012 я смог достичь того же результата проще, чем в принятом решении.
Я изменил опцию в меню инструменты → опции → проекты и решения → построить и запустить → * MSBuild проект сборки вывода многословие " от минимальный до Диагностика.
затем в выходных данных сборки я нашел те же строки, выполнив поиск "не в курсе":
проект "blabla" не актуален. C:\foo\bar пункт проекта.xml имеет атрибут "копировать в выходной каталог", установленный в "копировать всегда".
Это случилось со мной сегодня. Я смог отследить причину: проект включал файл заголовка, который больше не существовал на диске.
удаление файла из проекта решило проблему.
мы также столкнулись с этой проблемой и выяснили, как ее решить.
проблема была, как указано выше " файл больше не существует на диске."
Это не совсем верно. Файл существует на диске, но .Файл VCPROJ ссылается на файл где-то еще.
вы можете "обнаружить" это, перейдя в "Включить представление файла" и нажав на каждый включить файл по очереди, пока не найдете тот, который Visual Studio не может найти. Затем вы добавляете этот файл (как существующий элемент) и удалить ссылку, которая не может быть найдена, и все в порядке.
допустимый вопрос: как Visual Studio может даже создавать, если она не знает, где находятся включенные файлы?
мы думаем .файл vcproj имеет некоторый относительный путь к файлу-нарушителю, который он не показывает в графическом интерфейсе Visual Studio, и это объясняет, почему проект будет фактически построен, даже если древовидное представление includes неверно.
принятый ответ помог мне на правильном пути, чтобы выяснить, как решить эту проблему для испорченного проекта, с которым я должен был начать работать. Однако мне пришлось иметь дело с очень большим количеством плохих заголовков include. С подробным выводом отладки удаление одного из них привело к замораживанию IDE в течение 30 секунд при выводе отладочной извержения, что сделало процесс очень медленным.
Я удалил cpp и некоторые заголовочные файлы из решения (и с диска), но все еще имел проблему.
дело в том, что каждый файл, используемый компилятором, идет в *.файл tlog в каталоге temp. Когда вы удаляете файл, это *.файл tlog не обновляется. Этот файл используется инкрементными сборками для проверки актуальности проекта.
изменить это .tlog файл вручную или очистить проект и перестроить.
у меня была аналогичная проблема, но в моем случае отсутствовали файлы, была ошибка в определении выходного файла pdb: я забыл суффикс .pdb (я узнал с трюком ведения журнала отладки).
чтобы решить проблему, я изменил в файле vxproj следующую строку:
у меня была эта проблема в VS2013 (обновление 5), и для этого может быть две причины, обе из которых вы можете найти, включив "подробный" вывод сборки в разделе "Инструменты"->"проекты и решения"->"сборка и запуск".
Я не знаю, есть ли у кого-то еще такая же проблема, но свойства моего проекта имели "Configuration Properties" -> C/C++ -> "Debug Information Format" установите значение "нет", и когда я переключил его обратно на" базу данных программы по умолчанию (/Zi)", это остановило проект от перекомпиляции каждый раз.
еще одно простое решение, на которое ссылается Форум Visual Studio.
изменение конфигурации: menu инструменты → опции → проекты и решения → настройки проекта VC++ → Режим Обозревателя Решений to показать все файлы.
затем вы можете увидеть все файлы в обозревателе решений.
найти файлы, отмеченные желтым значком и удалять их из проект.
Я встретил эту проблему сегодня, однако это было немного по-другому. У меня был проект CUDA DLL в моем решении. Компиляция в чистом решении была в порядке, но в противном случае она не удалась, и компилятор всегда рассматривал проект DLL CUDA как не обновленный.
Я попробовал решение от этот пост.
но в моем решении нет отсутствующего файла заголовка. Затем я выяснил причину в моем случае.
Я изменил промежуточный каталог проекта раньше, хотя неприятностей это не доставило. и теперь, когда я изменил промежуточный каталог проекта CUDA DLL на $(Configuration)\, все снова работает правильно.
Я думаю, что есть небольшая проблема между настройкой сборки CUDA и не стандартным промежуточным каталогом.
у меня была аналогичная проблема и я следовал приведенным выше инструкциям (принятый ответ), чтобы найти отсутствующие файлы, но не без почесывания головы. Вот мое резюме того, что я сделал. Чтобы быть точным, это не отсутствующие файлы, так как они не требуются проекту для сборки (по крайней мере, в моем случае), но они являются ссылками на файлы, которые не существуют на диске, которые на самом деле не требуются.
вот моя история:
под Windows 7 файл находится по адресу %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . Есть два похожих файла devenv.exe.config.config и devenv.exe.config . Ты хочешь переодеться позже.
в Windows 7 у вас нет разрешения на редактирование этого файла в program files. Просто скопируйте его где-нибудь еще (рабочий стол), измените его и скопируйте обратно в папку program files.
у меня было много файлов, ненужных ссылок и удаление их всех исправили проблему, описанных выше.
Второй способ найти все отсутствующие файлы сразу
существует второй способ найти эти файлы сразу, но он включает в себя (a) управление версиями и (b) интеграцию с Visual Studio 2010. Использование Visual Studio 2010, добавьте свой проект в нужное место или фиктивное место в системе управления версиями. Он попытается добавить все файлы, в том числе те, которые не существуют на диске, а также ссылки в файле проекта. Перейти к программному обеспечению управления версиями, как необходимости, и он должен отметить эти файлы, которые не существуют на диске в другой цветовой схеме. Волей-неволей показывает их с Черным замком. Эти недостающие ссылки. Теперь у вас есть список все они, и вы можете удалить их все из своего файла проекта с помощью блокнота, и ваш проект не будет жаловаться на то, что от дата.
Visual Studio 2013 -- "принудительная перекомпиляция всех исходных файлов из-за отсутствия PDB". Я включил подробный вывод сборки, чтобы найти проблему: я включил" подробный "вывод сборки в разделе "Инструменты" → "проекты и решения" → "сборка и запуск".
У меня было несколько проектов, все C++, я установил опцию для параметров проекта: (C / C++ → формат отладочной информации) в базу данных программы (/Zi) для проблемного проекта. Однако это не остановило проблему для этого проекта. Проблема пришла из одного из других проектов C++ в решении.
Я все проекты C++ в "Program Database (/Zi)". Это исправило проблему.
опять же, проект, сообщающий о проблеме, не был проблемным проектом. Попробуйте установить все проекты в " Program Database (/Zi)", чтобы устранить проблему.
для меня это было наличие несуществующего файла заголовка в "файлах заголовков" внутри проекта. После удаления этой записи (щелкните правой кнопкой мыши > исключить из проекта) первый раз перекомпилируется, а затем напрямую
========== сборка: 0 успешно, 0 не удалось, 5 обновлено, 0 пропущено ==========
и не было предпринято никаких попыток восстановления без изменений. Я думаю, что это проверка перед сборкой, реализованная VS2010 (не уверен, что документально, может быть), которая запускает "AlwaysCreate" флаг.
Если вы используете команду MSBuild командной строки (не Visual Studio IDE), например, если вы нацеливаете AppVeyor или просто предпочитаете командную строку, вы можете добавить этот параметр в командную строку MSBuild:
как документально здесь (предупреждение: обычная многословность MSDN). Когда сборка завершится, найдите строку will be compiled в файле журнала, созданном во время сборки, MyLog.log .
Я использую Visual Studio 2013 Professional с обновлением 4, но не нашел разрешения ни с одним из других предложений, однако мне удалось решить проблему для моего командного проекта.
вот что я сделал, чтобы вызвать проблему -
- создан новый объект класса (Project -> Add Class)
- переименовал файл через Обозреватель решений и нажал да, когда меня спросили, хочу ли я автоматически переименовать все ссылки на матч
вот что я сделал, чтобы решить проблему -
- перейдите в Team Explorer Home
- Нажмите Проводник Управления Версиями
- перейдите в папку, в которой находятся все файлы класса/проекта
- нашел исходное имя файла в списке и удалил его с помощью правой кнопки мыши
- построить
Если это так для вас, просто убедитесь, что вы удаляете фантомный файл, а не фактический тот, который вы хотите сохранить в проекте.
у меня была эта проблема и я нашел это:
устранение:
в моем случае один из проектов содержит несколько файлов IDL. Компилятор MIDL создает файл данных DLL с именем " dlldata.c ' для каждого из них, независимо от имени файла IDL. Это заставило Visual Studio компилировать файлы IDL в каждой сборке, даже без изменений в любом из файлов IDL.
обходным путем является настройка уникального выходного файла для каждого файла IDL (компилятор MIDL всегда генерирует такой файл, даже если параметр / dlldata опущено):
- щелкните правой кнопкой мыши файл IDL
- выберите свойства-MIDL-выход
- введите уникальное имя файла DllData Файл свойства
Я потратил много часов на то, чтобы рвать на себе волосы. Результат сборки не был согласованным; разные проекты будут "не актуальными" по разным причинам от одной сборки до следующей последовательной сборки. В конце концов я обнаружил, что виновником был в Dropbox (3.0.4). Я соединяю исходную папку . \DropBox в папку " Мои проекты "(не уверен, что это причина), но DropBox как-то" касается " файлов во время сборка. Приостановлена синхронизация и все постоянно вверх-к-дата.
существует довольно много потенциальных причин, и, как уже отмечалось, вам нужно сначала диагностировать их, установив MSBuild многословие в "Diagnostic". В большинстве случаев указанная причина будет объяснительной, и вы сможете действовать на нее немедленно, но иногда MSBuild ошибочно утверждает, что некоторые файлы изменены и должны быть скопированы.
Если это так, вам нужно либо отключить туннелирование NTFS, либо дублировать выходную папку в новое место. здесь это больше словами.
для меня проблема возникла в проекте WPF, где у некоторых файлов было свойство "Build Action" установлено в "Resource", а их "Copy to Output Directory" установлено в "Copy if newer". Решение, казалось, состояло в том, чтобы изменить свойство "копировать в выходной каталог" на "не копировать".
msbuild знает, что нельзя копировать файлы "ресурсов" в выходные данные, но все равно запускает сборку, если их нет. Может, это можно считать ошибкой?
Это очень полезно, с ответами здесь намекая, как заставить msbuild пролить бобы на то, почему он продолжает строить все!
Это случилось со мной несколько раз, а затем ушло, прежде чем я смог понять, почему. В моем случае это было:
неправильное системное время в настройке двойной загрузки!
из-за невезения я построил проект один раз, с неправильным системным временем, а затем поправил время. В результате все файлы сборки имели неправильные метки времени, и VS подумал бы, что все они устарели, и перестроил бы проект.
большинство систем сборки используют метки времени данных, чтобы определить, когда должны произойти перестройки - отметка даты/времени любых выходных файлов проверяется на последнее измененное время зависимостей-если какая-либо из зависимостей более свежая, то цель перестраивается.
Это может вызвать проблемы, если какая-либо из зависимостей каким-либо образом получает недопустимую метку времени данных, поскольку трудно, чтобы метка времени любого вывода сборки когда-либо превышала метку времени файла, предположительно созданного в будущее :Р
у меня была аналогичная проблема с Visual Studio 2005, и мое решение состояло из пяти проектов в следующей зависимости (сначала построенной сверху):
я обнаружил, что проект Video_Codec хотел полную сборку даже после полной очистки, а затем перестроить решение.
я исправил это путем обеспечения pdb выходной файл как C / C++, так и компоновщика соответствовал местоположению, используемому другими рабочими проектами. Я также включил RTTI.
еще один на Visual Studio 2015 SP3, но я столкнулся с аналогичной проблемой в Visual Studio 2013 несколько лет назад.
моя проблема заключалась в том, что для предварительно скомпилированных заголовков использовался неправильный файл cpp (поэтому у меня было два файла cpp, которые создали предварительно скомпилированные заголовки). Теперь, почему Visual Studio изменила флаги на неправильном cpp для "создания предварительно скомпилированных заголовков" без моего запроса, я понятия не имею, но это произошло. может, какой-нибудь плагин.
в любом случае, неправильный файл cpp включает в себя версию.H файл, который изменяется при каждой сборке. Таким образом, Visual Studio перестраивает все заголовки и из-за этого весь проект.
Ну, теперь он вернулся к нормальному поведению.
Я пытался заставить работать Visual C ++, но я получаю эту ошибку при сборке каждого проекта: «Этот проект устарел», «Хотели бы вы построить его?» Это не удается построить каждый раз.
Решение
Что такое файлы tlog?
Эта информация используется и обновляется в следующий раз, когда вы запускаете сборку, чтобы помочь обнаружить «устаревшие» файлы и, таким образом, позволить системе сборки создавать только те биты, которые необходимо перестроить (а не собирать все заново).
Что вызывает проблему «устаревшего»?
Проблема может быть вызвана неправильной или устаревшей информацией в *.tlog файлы.
Существует 3 основных способа:
2) Ваш «Проект» имеет ссылки на файлы (обычно заголовочные файлы), которые не существуют в указанном месте. Это может произойти, если вы удалили файл из системы управления версиями, но забыли удалить его из своего проекта, или потому что вы ссылаетесь на заголовочные файлы библиотеки, которые могут быть «установлены» / представлены в другом месте. Разработчики часто предполагают, что файлы находятся в одном и том же «месте» на любой машине… не всегда так!
убедитесь, что ваш проект не ссылается на несуществующие файлы
Как мне определить, какие файлы не существуют?
В devenv.exe.config вы положили:
Подробнее
Допустим, вы создали решение и набор проектов в определенном каталоге, например, S: \ MYPROJECTS, и вы компилируете и запускаете / отлаживаете его и т. Д.
Затем вы решаете переместить весь этот каталог в другое место на вашем диске, или вы перефакторили свои проекты, например. изменить имена каталогов и т. д.
Теперь, когда вы делаете «Начать отладку / F5», Visual Studio выполняет проверку зависимостей и думает, что у вас есть «устаревшие файлы».
Другие решения
Вы должны позволить Visual Studio сообщить вам, почему он нуждается в восстановлении. Visual Studio 2015 имеет встроенную поддержку для этого:
- Инструменты (меню)
- Опции
- Проект и Решение
- Построить и запустить
Измените многословность вывода сборки проекта MSBuild на детализированный или Диагностика.
У меня тоже была эта пробема.
В моем случае причиной были ссылки на файлы (обычно заголовочные файлы), которые не существуют в указанном месте.
Я столкнулся с этой проблемой и, используя уловку диагностики, о которой писал Колинсмит, смог отследить проблему до того факта, что мой .vcxproj ссылался на файл, который фактически нигде не существовал (он был удален давно , но никогда не удаляется из файла проекта).
Просто для потомков у меня возникла эта проблема, а затем я понял, что мои компьютерные часы как-то прыгнули примерно на 48 часов в прошлое. После того, как я вернул его к текущему времени, предупреждение исчезло.
чтобы обновить проект, созданный в более ранней версии Visual Studio, просто откройте проект в последней версии Visual Studio. Visual Studio предлагает обновить проект до текущей схемы.
Если вы выберете " нет", проект не будет обновлен. для проектов, созданных в Visual Studio 2010 и более поздних версий, можно по-прежнему использовать проект в более новой версии Visual Studio. Просто задайте свойства проекта, чтобы они продолжали работать с более старым набором инструментов. если вы оставляете старую версию Visual Studio на компьютере, его набор инструментов доступен в более поздних версиях. например, если проект должен продолжать работать в Windows XP, можно выполнить обновление до Visual Studio 2019. Затем вы указываете набор инструментов в качестве v141_xp или более ранней версии в свойствах проекта. Дополнительные сведения см. в разделе Использование собственного многоплатформенного нацеливания в Visual Studio для сборки старых проектов.
Если выбрать Да, проект будет обновлен на месте. Его нельзя преобразовать обратно в предыдущую версию. В сценариях обновления рекомендуется создать резервную копию существующих файлов проекта и решения.
Обновление отчетов
При обновлении проекта появляется отчет об обновлении. Отчет также сохраняется в папке проекта как UpgradeLog.htm. В отчете об обновлении отображается сводка проблем, обнаруженных во время преобразования. В нем перечислены некоторые сведения о внесенных изменениях, включая:
Код, который больше не компилируется четко из-за улучшения соответствия компилятора или изменений в стандарте.
код, основанный на Visual Studio или Windowsных функциях, которые больше не доступны. или файлы заголовков, которые не включаются в установку по умолчанию Visual Studio или были удалены из продукта.
Код, который больше не компилируется из-за изменений в API, таких как переименованные API, измененные сигнатуры функций или устаревшие функции.
Код, который больше не компилируется из-за изменений в диагностике, например предупреждения об ошибке
Ошибки компоновщика из-за измененных библиотек, особенно при использовании параметра/NODEFAULTLIB.
Ошибки времени выполнения или непредвиденные результаты из-за изменений в поведении.
Ошибки, появившиеся в средствах. если у вас возникла ошибка, сообщите о ней команде Visual C++ по стандартным каналам поддержки или с помощью страницы Community Visual Studio разработчика C++ .
Некоторые обновленные проекты и решения могут быть успешно собраны без изменений. Однако большинству проектов, скорее всего, потребуется внести изменения в параметры проекта и исходный код. Не существует единого правильного способа устранения этих проблем, но мы рекомендуем использовать поэтапный подход. Прежде чем начать, ознакомьтесь с обзором возможных проблем с обновлением , чтобы получить дополнительные сведения о многих типичных ошибках.
задайте предпочтительные версии набора инструментов платформы, стандарта языка C++ и Windows SDK версии (если применимо). (Project > Свойства > Свойства конфигурации > Общие)
При наличии большого количества ошибок можно временно отключить некоторые параметры, пока вы их исправите. чтобы отключить этот /permissive- параметр, используйте Project > свойства > конфигурации свойства > языка C/C++ > . чтобы отключить параметр анализа кода , используйте свойства конфигурации Project > свойства > > Code Analysis.
Убедитесь, что все зависимости существуют и что пути к включаемым файлам или папкам библиотеки указаны правильно. (Project > Свойства > Свойства конфигурации > VC++ каталоги)
Выявление и устранение ошибок, вызванных ссылками на интерфейсы API, которые больше не существуют.
Устраните все оставшиеся ошибки, препятствующие компиляции. Сведения об устранении распространенных ошибок см. в статье Обзор возможных проблем с обновлением .
Снова включите /permissive- и исправьте все новые ошибки, вызванные несоответствием коду, который ранее был скомпилирован в MSVC.
Включите анализ кода, чтобы выявление потенциальных проблем или устаревших шаблонов кода, которые больше не считаются приемлемыми. Если анализ кода помечает много ошибок, можно отключить некоторые предупреждения, чтобы сосредоточиться на наиболее важных. Интегрированная среда разработки может помочь быстро устранить проблемы некоторых типов.
Рассмотрим другие возможности для модернизации кода. Например, замените пользовательские структуры данных и алгоритмы на шаблоны из стандартной библиотеки C++ или в библиотеку с открытым исходным кодом. Используя стандартные функции, можно упростить поддержку кода другими пользователями. Можно быть уверенным, что этот код тщательно проверен и проверен многими экспертами по стандартам и широкому сообществу C++.
Я пытаюсь заставить Visual С++ работать, но я получаю эту ошибку при создании каждого проекта: "Этот проект устарел" "Хочешь его построить?" Он не может создавать каждый раз.
Я получаю эту ошибку: проект не обновляется, потому что "вставить имя файла здесь". отсутствует.строить состояние.. Обратите внимание, что в реальной визуальной студии ничего не регистрируется. Я не смог найти что-либо в этом в google. Возможно, я неправильно включил ведение журнала, но я чувствую, что это ошибка.
Я искал 3 часа, я не могу найти ничего, чтобы помочь с этим. Если вы нашли что-то, что может помочь, пожалуйста, направьте меня к этому. Если вы открываете Visual Studio и пытаетесь скомпилировать свой проект / решение вручную, там появляются какие-либо ошибки? (Это проблема с регистрацией или вашим кодом?) Кроме того, имейте в виду, что проект устарел, вероятно, потому, что он никогда не был успешно собран, и что причина, по которой он не может быть собран, не имеет ничего общего ни с последним состоянием сборки, ни с вашей регистрацией. Устаревший проект - это не ошибка, а просто интерес. Вы можете отключить этот диолог в опциях Visual Studio, но это не сделает ваш проект волшебным образом скомпилированным, и не решит проблемы с журналированием. Это также может быть вызвано тем, что файлы в вашем решении больше не существуют на диске, поэтому проверка метки даты и времени завершается неудачно и всегда считает ее устаревшей. Когда я копировал папку проекта с одного компьютера на другой и пытался собрать и запустить ее в режиме отладки, я продолжал получать эту «ошибку». Включение ведения журнала диагностики показало, что был указан AlwaysCreate, что многие другие, по-видимому, видели, когда отсутствует заголовочный файл, но мой проект настолько прост, просто заголовочный файл и основной файл cpp, поэтому у меня нет шансов, что это так. , Так что, возможно, одна из внешних зависимостей отсутствовала, так как она была скомпилирована на другом компьютере с (потенциально) другой загрузкой Visual Studio 2010 Express (рабочее место слишком дешевое, чтобы платить за него).Что такое файлы tlog?
"tlog" файлы создаются процессом "Tracker.exe", который выполняется во время сборки, и записывает некоторую информацию о сборке.
Эта информация используется и обновляется при следующем запуске сборки, чтобы обнаруживать "устаревшие" файлы и, таким образом, позволяет сборке строить только биты, которые необходимо перестроить (а не строить все снова).
Что вызывает проблему "устаревшего"?
Проблема может быть вызвана неправильной или устаревшей информацией в файлах *.tlog .
Существует 3 основных способа:
1) Вы создали проект на своем жестком диске, а затем переместили каталог в другое место. файлы "tlog" записывали пути старого местоположения, но поскольку вы перемещали файлы, их больше нет, таким образом, вы получаете "устаревшие".
2) В вашем "Проекте" есть ссылки на файлы (обычно заголовочные файлы), которых нет в указанном месте. Это может произойти, если вы удалили файл из исходной системы управления, но забыли удалить его из своего проекта или потому, что ссылаетесь на файлы заголовков библиотеки, которые могут быть "установлены" /присутствовать в другом месте. Часто разработчики предполагают, что файлы находятся в одном и том же "месте" на каждой машине. не всегда в этом случае!
3) Вы сделали "рефакторинг" своего проекта и переместили файлы в разные подкаталоги или даже переименовали их, поэтому пути/имена файлов, записанных в "tlog" , не соответствуют тому, что существует на вашем диск, т.е. устаревший.
Выполнение "Clean + Build" или "Rebuild" не всегда фиксирует это. поскольку эти операции не удаляют файлы "tlog" . Итак:
удалите все файлы "tlog" , которые вы можете найти в своих каталогах решений/проектов и перестройте.
убедитесь, что ваш проект не ссылается на несуществующие файлы
Как я могу определить, какие файлы не существуют?
В devenv.exe.config вы помещаете:
Подробнее
Предположим, вы создали решение и набор проектов в определенном каталоге, например. S:\MYPROJECTS, и вы компилируете и запускаете/отлаживаете его и т.д.
Затем вы решите переместить весь этот каталог в другое место на своем диске или перегруппировать свои проекты, например. изменить их имена каталогов и т.д.
Теперь, когда вы выполняете "Начать отладку /F 5", Visual Studio выполняет зависящую проверку и думает, что у вас есть "устаревшие файлы".
Проблема вызвана файлами ".tlog", с которыми консультируются во время проверок зависимостей. при перемещении решений/проектов (вместе с промежуточными файлами сборки) они вызывают путаницу с компоновщиком Visual Studio.
В наше время open source проекты все популярнее. На площадках открытых проектов, например, на github можно найти множество полезных программ, но они не всегда имеют исполняемые файлы ("exe"), поэтому я постараюсь рассказать о том, как можно собрать самостоятельно C/C++ программу, из исходников, написанную на Microsoft Visual Studio.
Первым делом нам необходимо загрузить онлайн установщик Microsoft Visual Studio, с официального сайта. Для компиляции С/С++ проектов нет необходимости во всех пакетах и можно выбрать только те, которые нам необходимы.
Установщик загрузит необходимые пакеты из интернета и установит их.
После установки Visual Studio можно убедиться, что всё работает создав тестовый проект и скомпилировав его. Для этого нажмите в меню "Файл" → "Создать" → "Проект. "
После чего появится диалог выбора типа проекта, где можно выбрать:
- Консольное приложение;
- Классическое приложение;
- Библиотеку динамической компоновки (dll);
- Статическую библиотеку;
В нашем случае для быстрой проверки подойдет консольное приложение, выбираем название и папку проекта , после чего жмём кнопку "ОК" и создается наша программа.
После этого остается остается лишь скомпилировать её, для этого нужно выбрать в меню "Сборка" и нажать на пункт "Собрать решение".
Далее наш проект скомпилируется и в папке проекта появится наш тестовый исполняемый файл ("exe").
Если всё работает как надо, то можно приступать к сборке какого-нибудь другого открытого проекта с github или другого хостинга проектов.
Первым делом нам нужно загрузить исходники проекта. На площадке github это делается довольно просто, жмем на кнопку "Code" и "Download ZIP". После чего нужно распаковать его и можно приступать к сборке.
Ищем файл с расширением "<название_проекта>.vcxproj" и запускаем его. Перед нами появится диалог в котором нам предложат обновить SDK проекта (набор библиотек для разработки, которые Microsoft периодически обновляет) и набор инструментов, жмём обновить.
Теперь наш проект можно собрать, но до сборки необходимо выбрать разрядность проекта (например, для 32 битной системы или 64 битной), а также тип сборки (отладочный режим - debug или release).
Выбираем 64 битную систему и тип сборки релиз, после чего компилируем проект. Как и ранее нужно выбрать в меню "Сборка" и нажать на пункт "Собрать решение".
Некоторые проектам требуется вручную изменить SDK и набор инструментов, на установленный у вас, для этого идём в свойства проекта, выбираем сверху типа сборки и разрядность системы и уже там изменяем SDK и набор инструментов. В выпадающем меню появляются установленные у нас версии, выбираем их и нажимаем "ОК". После чего наш проект скомпилируется.
Бывает, что проект использует сторонние библиотеки, для этого их нужно загрузить отдельно и положить в папку. Узнать путь или изменить его можно в свойстве проекта, в разделе "С/C++" → "Общие" → "Дополнительные каталоги включаемых файлов".
Бывает, что SDK или набор инструментов, в свойстве проекта не изменяется в диалоге, чтобы изменить их нужно записать номер SDK, закрыть Visual Studio и вручную, блокнотом изменить этот номер в файле проекта "<название_проекта>.vcxproj".
При возникновении других проблем можно попробовать их загуглить, возможно, что кто-то уже сталкивался с ними и решил их.
Читайте также: