Проект не выбран для сборки в данной конфигурации решения visual studio
Я отлаживаю чужую работу, и решение довольно велико. Когда я пытаюсь собрать все целиком, несколько проектов в рамках решения не создаются, а просто пропускаются. Просмотр окна вывода во время процесса сборки говорит:
Как я могу определить, почему эти сборки были пропущены? Я не могу найти дополнительный вывод.
Щелкните правой кнопкой мыши решение, выберите «Свойства», а затем «Свойства конфигурации». Здесь вы можете выбрать, какие проекты строить.
[ Правка ]:
См. Комментарий Kdt: . когда я посмотрел в свойствах конфигурации . цель сборки проекта была настроена для "Смешанных платформ", в то время как решение было настроено на сборку "Любой ЦП".
* Когда эта проблема случилась со мной, в основном проекте был только «Любой ЦП», и он также установил для дочерней библиотеки «Любой ЦП», однако я удалил этот профиль и оставил только «x86». Выбор x86 только для DLL, чтобы он начал работать
[/редактировать]
У меня просто была одна и та же проблема - «выгрузить проект» и «перезагрузить проект» решил проблему!
Если значение конфигурации x64 и x64 компилятор не установлен, проект будет пропущен.
Операции по сборке, перестройке и очистке пропускались. Выгрузка и перезагрузка не помогли, равно как и перезапуск Visual Studio.
Как только я удалил проект из решения и добавил его обратно, он больше не пропускается. Чтобы удалить его, в обозревателе решений щелкните правой кнопкой мыши проект> Удалить> ОК. Чтобы добавить его обратно, в обозревателе решений щелкните правой кнопкой мыши решение> Добавить> Существующий проект и выберите свой проект.
Visual Studio 2008, это может быть потому, что 64-битный компилятор не был бы установлен.
Панель управления -> Программы и компоненты -> Microsoft Visual Studio 2008 professional -> [двойной щелчок]
В диалоге Visual Studio
Далее -> Добавить/удалить компоненты -> (Под) Visual C++ -> (выбрать) x64 компилятор и инструменты
Эй, только что исправил это. Думаю, это может помочь. Скорее всего, вы не устанавливали соответствующие компиляторы вместе с Visual Studio. Это случилось со мной сегодня - по умолчанию установщик VS 2008 не устанавливает x64 C++ компилятор.
Если у вас есть SP1, удалите его перед изменением установки VS. Когда закончите, установите SP1 снова.
Проблема существует и в VS 2010; из предложенных решений: редактирование конфигурации сборки, очистка, изменение/изменение целевой структуры, НЕ работают. Но выгрузка и перезагрузка проекта делает.
Зайдите в меню сборки и выберите «Диспетчер конфигурации». Это покажет, какие проекты настроены для построения в выбранной вами конфигурации.
Если бы возникла та же проблема, выяснилось, что настройки проекта были для процессора Itanium, а изменение на Intel исправило.
Щелкните правой кнопкой мыши на Solution в вашем обозревателе решений, затем выберите Property в нижней части меню. В окнах свойств нажмите Свойства конфигурации -> Конфигурация на левой панели, вы увидите список проектов на правой панели, убедитесь, что во всплывающем окне установлен флажок Построить.
Если ваше решение содержит файл проекта NuGet (* .nuproj), попробуйте выгрузить его, а затем пересобрать решение.
Это сработало для меня после того, как ничего из вышеперечисленного не сработало.
Работал с той же проблемой с VS2005, все конфигурации были правильными . Он даже пропускал команду Очистить проект.
Наконец выгрузка/перегрузка сделали волшебство.
Мое решение такое же, как упомянуто ранее: Удалить -> Добавить существующий проект
Но Это решение подразумевает, что ссылки между проектами исчезают
Чтобы избежать повторного добавления ссылок: и в случае, если вы используете систему контроля версий , например, GIT или TFS или что-то еще, можно достичь цели с помощью следующих шагов:
Просмотрите все проекты, исключив их из решения и добавив к ним существующие.
Обратите внимание, что файл .sln изменился
Сохраните новый файл .sln, но отмените изменения всех файлов .cspoj в системе контроля версий
Щелкните правой кнопкой мыши проект в файле решения, выберите свойства, вкладку приложения, измените целевой фреймворк с 4.0 на 3.5.
Затем перестройте, и я получил кучу пропущенных ошибок ссылок на сборки, что имеет смысл, поскольку я еще не добавил ссылки на них.
У меня была похожая проблема, у меня был один проект, который по какой-то причине не мог загрузиться в обозревателе решений. Когда я загрузил этот проект, он работал как шарм.
VS 2008 будет пропускать цели x64, если у вас не установлен x64 компилятор. VS 2008 не по умолчанию. Вроде дух, вещь.
Я обнаружил, что иногда, когда у вас есть целевая платформа, настроенная на, скажем, x86 в вашем решении, а в ваших проектах проект не всегда был выбран.
Для двойной проверки перейдите в свойства проекта и посмотрите, можете ли вы выбрать эту платформу в настройке Build-> Platform, если не можете, то вам нужно будет перейти к диспетчеру конфигурации и создать эту конфигурацию.
я обновился до 15.9.11, . после некоторых сборок та же проблема: большинство проектов пропускаются (которые строятся секунду назад без проблем). Разгрузка/перезагрузка решения всегда помогает в моем случае, но это скоро произойдет снова.
Я понятия не имею, почему . кроме большой ошибки в VS2017
Я проверил диспетчер конфигурации, все галочки установлены для сборки.
Возможно, это как-то связано с пакетами nuget, но это только предположение
Решение имеет только c ++/vcxproj, но не csproj. 64 и 32 установлены оба
сначала убедитесь, что вы выполняете «чистую» очистку. Visual Studio, как правило, не будет перестраивать проект, который не устарел (насколько это возможно), и будет просто повторно использовать объектный код, который у него уже есть.
Запуск clean должен очистить весь ранее скомпилированный код, а VS не должен пропускать проект (при условии, что менеджер конфигурации выбрал проекты для сборки . см. Предыдущий ответ).
Надеюсь, это поможет.
Я обновляю одно небольшое обновление Visual Studio 2017, а затем установщик напоминает мне перезагружать компьютер, но я не перезагружаюсь. Когда я строю свой проект или решение в Visual Studio 2017, я сталкиваюсь с той же проблемой, описанной выше. ключ, поэтому я перезагрузил компьютер, я сделал это.:>
У меня был странный, который, возможно, стоит документировать среди других возможностей здесь ..
Я добавил Shared Project к своему решению с кодом, который использовался в двух или трех других проектах. Как вам известно, общие проекты - это просто код, а не проект в традиционном смысле. Вы не можете «построить» общий проект, это просто код, который встроен в другие проекты, а затем встроен в него.
Но каким-то образом мой файл решения был обновлен так, как если бы общий проект был его собственной задачей, которую нужно было собрать. Я предполагаю, что всякий раз, когда я пытался собрать и не менял код в общем проекте, он полагал, что «ничего не изменилось, пропустите эти сборки»
Я нашел общий проект в файле solution.sln , например:
.. что хорошо. То, что не хорошо, - то, что этот проект также появился в GlobalSection(ProjectConfigurationPlatforms) = postSolution как:
Я удалил эти четыре строки из своего файла .sln , и теперь все снова кажется счастливым
У меня была эта проблема с некоторыми проектами Windows CE на новом ПК. «Unload project» и «Reload project», по-видимому, решали проблему, но на самом деле Visual Studio просто переключилась на другую платформу и создала ее.
Оказалось, что хотя моя платформа WinCE была показана как активная платформа, Visual Studio "действительно" не видела ее. Решением было переустановить WinCE SDK с привилегиями администратора :
- Убедитесь, что Visual Studio 2008 не работает.
- Откройте «Командная строка Visual Studio 2008» в качестве администратора. В Windows 7 просто щелкните правой кнопкой мыши по ярлыку и выберите «Запуск от имени администратора».
- Введите следующую команду: msiexec /log SDKInstallLog.txt /package <the path to your .msi file>
- Когда вас спросят, хотите ли вы выполнить выборочную или полную выборку установки, и попросите установщика пропустить установку документации (этот шаг не был необходим в моем случае; на самом деле я просто попросил его «восстановить» существующую установку). )
- Устанавливать
У меня была похожая вещь, случившаяся со мной. Я не уверен, в чем проблема, но это не будет Очистить , Сборка , Перестроить и т.д. Я работаю в Visual Studio 2017 и хотел сборку netstandard2.0 , Проблема для меня заключалась в том, что каким-то образом тип проекта был неправильным, может быть, я начал с библиотеки классов netcoreapp , что-то вроде этого, застрявшее в файле Solution , я не помню. Как бы то ни было, я сделал резервную копию проекта, создал новый проект библиотеки классов netstandard , и учел в битах резервной копии, и это исправило это для меня. HTH кто-то.
Я только попал в эту проблему:
- Я разгрузил каждый проект и перезагрузил их.
- Закрыл все экземпляры VS и открыл VS как администратор (щелкните правой кнопкой мыши по ярлыку и выберите опцию «Запуск от имени администратора»)
Вот и все, что вернулось в действие, и я смог успешно построить все проекты.
Конфигурации решения хранят свойства уровня решения. Они направляют поведение клавиши Start (F5) и команд сборки . По умолчанию эти команды создают и запускают конфигурацию отладки. Обе команды выполняются в контексте конфигурации решения. Это означает, что пользователь может запустить клавишу F5 и выполнить сборку любого активного решения, настроенного с помощью параметров. Среда разработана для оптимизации решений, а не проектов, когда дело доходит до сборки и запуска.
стандартная Visual Studio панель инструментов содержит кнопку «пуск» и раскрывающийся список конфигурации решения справа от кнопки «пуск». Этот список позволяет пользователям выбирать конфигурацию для запуска при нажатии клавиши F5, создавать собственные конфигурации решения или изменять существующую конфигурацию.
Нет интерфейсов расширяемости для создания или изменения конфигураций решения. Для этого необходимо использовать DTE.SolutionBuild . Однако существуют API расширяемости для управления сборкой решения. Дополнительные сведения см. в разделе IVsSolutionBuildManager2.
Вот как можно реализовать конфигурации решений, поддерживаемые типом проекта:
Отображает имена проектов, найденных в текущем решении.
Чтобы предоставить список конфигураций, поддерживаемых типом проекта и отображаемых на страницах свойств, реализуйте IVsCfgProvider2 .
В столбце Конфигурация отображается имя конфигурации проекта для сборки в этой конфигурации решения, а также список всех конфигураций проекта при нажатии кнопки со стрелкой. Среда вызывает GetCfgNames метод для заполнения этого списка. Если GetCfgProviderProperty метод указывает, что проект поддерживает редактирование конфигурации, то новые или изменения параметров также отображаются под заголовком конфигурации. Каждый из этих вариантов запускает диалоговые окна, вызывающие методы IVsCfgProvider2 интерфейса для изменения конфигураций проекта.
Если проект не поддерживает конфигурации, в столбце конфигурации отображается значение нет и он отключен.
Отображает платформу, для которой строится выбранная конфигурация проекта, и перечисляет все доступные платформы для проекта при нажатии кнопки со стрелкой. Среда вызывает GetPlatformNames метод для заполнения этого списка. Если GetCfgProviderProperty метод указывает, что проект поддерживает изменение платформы, то в разделе "платформа" также отображаются элементы "создать" и "Изменить". Каждый из этих вариантов запуска открывает диалоговые окна, вызывающие IVsCfgProvider2 методы для изменения доступных платформ проекта.
Если проект не поддерживает платформы, столбец платформа для этого проекта отображает нет и отключен.
Указывает, строится ли проект в текущей конфигурации решения. Невыбранные проекты не создаются при вызове команд сборки на уровне решения, несмотря на все зависимости проектов, которые они содержат. Проекты, не выбранные для построения, по-прежнему включены в отладку, запуск, упаковку и развертывание решения.
Указывает, будет ли проект развернут при использовании команд запуска или развертывания с выбранной конфигурацией сборки решения. Флажок для этого поля будет доступен, если проект поддерживает развертывание с помощью реализации IVsDeployableProjectCfg интерфейса для его IVsProjectCfg2 объекта.
После добавления новой конфигурации решения пользователь может выбрать ее из раскрывающегося списка Конфигурация решения на стандартной панели инструментов для построения и (или) запуска этой конфигурации.
Конфигурация в Configuration Manager кажется правильной:
Это код проекта, который я пытаюсь построить:
Что я пробовал до сих пор:
Переход с любого CPU на x86 и обратно.
Установите для флажка Build значение false, а затем верните значение true.
- 28 Выбрать Развернуть также из Configuration Manager для проекта Android.
- Вот и все, большое вам спасибо. Ошибка (Проект не выбран для строить для этой конфигурации решения) было немного запутанным, плюс все ответы на эту ошибку указывали на Построить флажок, а не Развернуть один. Будучи новичком в Xamarin, я не знал этого Развернуть на Android нужно было проверить, а проект в git по какой-то причине не проверял (при создании нового проекта Visual Studio флажок действительно установлен по умолчанию).
Как сказал Ковальски, вы должны проверить параметр развертывания в Configuration Manager. Щелкните решение правой кнопкой мыши и выберите Configuration Manager. Затем отметьте параметр развертывания для запускаемого проекта. Как это изображение
- Да, нам нужно установить флажок
- 2 Я столкнулся с этим на сервере сборки CI, и мне было достаточно проверить столбец сборки (он не был отмечен)
- Я столкнулся с той же проблемой при создании оконной службы с помощью сборки CI, я просто проверил столбец сборки, и у меня это сработало.
перейдите в Build => Configuration Manager. затем установите флажок развертывания для запускаемого проекта. Пс. не забудьте выбрать свой запускаемый проект, щелкнув правой кнопкой мыши проект => установить как запускаемый проект
В отличие от простейших программ, таких как "Hello World", большинство приложений состоит из нескольких исходных файлов. Это обстоятельство порождает массу проблем, в частности, как назвать файлы, где их разместить и можно ли их использовать повторно. В интегрированной среде разработки Visual Studio принята концепция решения (solution), состоящего из ряда проектов, которые в свою очередь состоят из ряда элементов, благодаря которой разработчики могут работать с исходными файлами. Интегрированная среда разработки имеет множество встроенных инструментов, позволяющих упростить этот процесс, обеспечив разработчикам доступ к большей части их приложений. Далее рассматриваются структура решений и проектов, доступные типы проектов и способы настройки их конфигурации.
Структура решения
Работая с системой Visual Studio, пользователь открывает решение. При повторном редактировании специальных файлов создается временное решение, которое можно уничтожить по окончании работы. Однако решение позволяет управлять текущими файлами, поэтому в большинстве случаев его сохранение означает, что пользователь может вернуться к тому, что он делал накануне, и вновь открыть файлы, с которыми он работал.
Наиболее распространенным способом структурирования приложений в среде Visual Studio является одно отдельное решение, содержащее много проектов. Каждый проект можно создать из набора исходных файлов и папок. Главное окно, в котором пользователь работает с решениями и проектами, называется Solution Explorer:
Для организации работы с исходным кодом и предотвращения его ассоциации с приложениями (за исключением веб-приложений, в которых существуют специальные папки, имеющие особое предназначение в данном контексте) используются папки (folders). Некоторые разработчики используют имена папок, соответствующие пространствам имен, которым принадлежат классы. Например, если класс Person находится в папке DataClasses в проекте FirstProject, то полностью квалифицированное имя класса может выглядеть как FirstProject.DataClasses.Person.
Папки решения (solution folders) - полезный способ организации проектов в большом решении. Они отображаются только в окне Solution Explorer - физически в файловой системе их не существует. Такие действия, как Build или Unload, можно легко выполнять над всеми проектами, включенными в папку решения. Для того чтобы разгрузить окно Solution Explorer, папки решения могут быть свернуты или скрыты.
Скрытые проекты по-прежнему создаются, когда пользователь создает решение. Поскольку папки проекта не соответствуют физическим папкам, их можно добавлять, переименовывать и удалять в любое время, не рискуя повредить связи между файлами или потерять контроль над исходными файлами.
Папка Miscellaneous Files - это специальная папка решения, которую можно использовать для того, чтобы следить за тем, какие еще файлы, не являющиеся частью какого-либо проекта в решении, были открыты в системе Visual Studio. По умолчанию папка Miscellaneous Files скрыта. Для того чтобы сделать ее видимой, следует выполнить команду Tools --> Options --> Environment --> Documents --> Show Miscellaneous Files.
Несмотря на то что формат файла решения, принятый в предыдущих версиях, не изменился, в системе Visual Studio 2010 открыть файл решения, созданный в версии Visual Studio 2013, невозможно.
Кроме информации о файлах, содержащихся в приложении, файлы решения и проектов могут содержать и другие записи, например, о том, как именно должен быть скомпилирован конкретный файл, об установках проекта, о ресурсах и многом другом. Система Visual Studio 2013 имеет немодальное диалоговое окно для редактирования свойств проекта, в то время как свойства решения по-прежнему открываются в отдельном окне. Как и следовало ожидать, свойствами проекта считаются те свойства, которые относятся только к данному проекту, например информация о сборке и связях, а свойства решения определяют общую конфигурацию для сборки приложений.
Формат файла решения
Система Visual Studio 2013 фактически создает для решения два файла, имеющих расширения .suo и .sln (solution file). Первый - это довольно неинтересный бинарный файл, который сложно редактировать. Он содержит информацию, специфичную для пользователя, например, какие файлы были открыты, когда решение закрывалось в последний раз и где находились контрольные точки. Этот файл скрыт, поэтому он не должен появляться в папке решения при использовании Windows Explorer, если не снять с него соответствующую метку.
Иногда файл .suo оказывается поврежденным, и это вызывает непредсказуемые последствия при сборке и редактировании приложений. Если при работе с конкретным решением система Visual Studio становится нестабильной, необходимо выйти из нее и удалить файл с расширением .suo. Он будет создан заново системой Visual Studio, когда решение будет открыто в следующий раз. Файл решения с расширением .sln содержит информацию о решении, например список проектов, конфигурации сборки и другие настройки, не специфичные для проекта. В отличие от многих файлов, используемых в системе Visual Studio 2013, файл решения не является XML-документом. Он хранит информацию в блоках, как показано в следующем примере:
В этом примере решение состоит из трех проектов (GettingStarted, Information Services и Reference Library), а раздел Global содержит настройки, которые применяются к решению. Например, само решение будет видимым в окне Solution Explorer, потому что настройка HideSolutionNode установлена равной FALSE. Если изменить ее на TRUE, имя решения не будет отображаться в системе Visual Studio.
Свойства решения
Для того чтобы открыть диалоговое окно Properties, необходимо щелкнуть правой кнопкой мыши на узле Solution в окне Solution Explorer и выбрать команду Properties. Это диалоговое окно содержит два узла: Common properties и Configuration properties, как показано на рисунке ниже:
Более подробно узлы Common properties и Configuration properties описываются в следующих разделах.
Узел Common Properties
Определяя проект Startup Project для приложения, пользователь имеет три возможности, которые являются практически очевидными. Выбор Current Selection запускает проект, который в данный момент находится в фокусе окна Solution Explorer. Вариант Single Startup гарантирует, что каждый раз будет запускаться один и тот же проект. Эта установка задается по умолчанию, поскольку большинство приложений имеют только один стартовый проект. Последний вариант, Multiple Startup Projects, позволяет запускать несколько проектов в определенном порядке. Это может быть полезным при работе с приложением клиент/сервер в рамках одного решения, причем требуется, чтобы и клиент, и сервер выполнялись одновременно. При выполнении нескольких проектов важно контролировать порядок их запуска. Для управления порядком запуска проектов можно использовать навигационные кнопки, расположенные после списка проектов.
Раздел Project Dependencies используется для того, чтобы задавать другие проекты, от которых зависит конкретный проект. В большинстве случаев система Visual Studio сама управляет этими свойствами, когда пользователь добавляет или удаляет связи между проектами и данным проектом. Однако иногда пользователь может самостоятельно создать связи между проектами, чтобы они собирались в заданном порядке. Система Visual Studio использует этот список зависимостей, для того чтобы определить порядок сборки проектов. Окно этого раздела предотвращает неосторожное добавление циклических связей и удаление необходимых зависимостей между проектами.
В разделе Debug Source Files можно создать список каталогов, в которых система Visual Studio может искать исходные файлы при отладке. Этот список задается по умолчанию и просматривается перед открытием диалогового окна Find Source. Кроме того, пользователь может перечислить исходные файлы, которые система Visual Studio не должна искать. Если щелкнуть на кнопке Cancel в момент, когда система предлагает найти конкретный исходный файл, то он будет добавлен в этот список.
Раздел Code Analysis Settings доступен только в версии Visual Studio Team Suite. Это позволяет выбирать набор правил статического анализа кода, которые будут применяться к конкретному проекту. Более подробно раздел Code Analysis обсуждается далее.
Узел Configuration Properties
И проекты, и решения имеют конфигурации для сборки, определяющие, какие элементы должны быть собраны и почему. Это может сбить пользователя с толку, потому что на самом деле между конфигурацией проекта, определяющей, как должны собираться элементы, и конфигурацией решения, определяющей, какие проекты должны быть собраны, нет никакой корреляции, кроме случаев, когда они имеют одинаковые имена. Новое решение определит конфигурации Debug и Release (решения), что эквивалентно сборке всех проектов в решении с помощью конфигураций Debug и Release (проекта).
Например, может быть создана новая конфигурация решения Test, состоящая из двух проектов: MyClassLibrary и MyClassLibraryTest. Когда пользователь создает свое приложение в конфигурации Test, он хочет, чтобы проект MyClassLibrary был собран в режиме Release, чтобы тестировать его в виде, максимально приближенном к окончательной версии. Однако, чтобы проверить тестируемый код, необходимо собрать тестовый проект в режиме Debug.
Когда пользователь собирает проект в режиме Release, он не хочет, чтобы решение Test было собрано или развернуто вместе с приложением. В данном случае в конфигурации решения Test можно указать, что пользователь хочет, чтобы проект MyClassLibrary был собран в режиме Release, а проект MyClassLibraryTest вообще не собирался.
Пользователь может легко переключаться между этими конфигурациями с помощью меню Configuration стандартной инструментальной панели. Однако, переключаться между платформами не так легко, потому что меню Platform нет ни в одной инструментальной панели. Для того чтобы сделать ее доступной, необходимо выбрать команду View --> Toolbars --> Customize. Затем элемент Solution Platforms из категории Build на закладке Command можно перетащить на инструментальную панель.
Следует отметить, что, выбрав узел Configuration Properties в диалоговом окне Solution Properties, как показано на рисунке ниже, можно получить доступ к раскрывающимся спискам Configuration и Platform. Раскрывающийся список Configuration содержит все доступные конфигурации решения: Debug и Release (заданные по умолчанию), Active и All Configurations. Аналогично в раскрывающемся списке Platform перечислены все доступные платформы. Как только пользователь получит доступ к этим раскрывающимся спискам, он может на этой же странице задать настройки для каждой конфигурации и/или платформы. Для того чтобы добавить новые конфигурации и/или платформы для решения, пользователь может также использовать кнопку Configuration Manager.
При добавлении новых конфигураций решения существует возможность (предусмотренная по умолчанию) создания соответствующих конфигураций для существующих проектов (по умолчанию все проекты будут собираться в новой конфигурации решения), а также возможность создать новую конфигурацию на основе существующих. Если флажок Create Project Configurations установлен и новая конфигурация основана на существующей, то новые конфигурации проекта будут копировать конфигурации проекта, заданные для существующей конфигурации.
Возможности, доступные для создания новых платформенных конфигураций, ограничены типами доступных центральных процессоров: Itanium, x86 и x64. Новая платформенная конфигурация также может основываться на существующих платформенных конфигурациях, и существует возможность создания платформенной конфигурации для проекта.
В конфигурационном файле решения можно также задать тип центрального процессора, для которого оно собирается. Это особенно удобно, если нужно развернуть приложение для компьютеров с 64-битовой архитектурой. Установить настройки для всех этих решений можно непосредственно в контекстном меню, которое открывается после щелчка правой кнопкой мыши на узле Solution node в окне Solution Explorer. В то время как команда Set Startup Projects открывает окно конфигурации решения, команды Configuration Manager, Project Dependencies и Project Build Order открывают окно Configuration Manager and Project Dependencies. Команды Project Dependencies и Project Build Order отображаются в окне, только если решение состоит из нескольких проектов.
Команда Project Build Order открывает окно Project Dependencies и перечисляет порядок сборки, как показано на рисунке ниже:
Закладка Build Order демонстрирует порядок, в котором должны собираться проекты в соответствии с зависимостями между ними. Это может оказаться полезным, если пользователь поддерживает ссылки на бинарные сборки проектов, а не ссылки на проекты. Кроме того, эту возможность можно использовать для двойной проверки того, что проекты будут собраны в правильном порядке.
БлогNot. Как собрать проект C++ с github из исходников и подключить его к Visual Studio
Как собрать проект C++ с github из исходников и подключить его к Visual Studio
Благодаря менеджеру пакетов winget, уже входящему в актуальные сборки масдайки, теперь в Windows 10 можно инсталлировать приложения одной простой консольной командой (см. также доку от Микрософта).
Но мы рассмотрим сейчас ситуацию, когда у нас есть только ссылка на исходники проекта, скажем, на Гитхабе (возьмём для примера библиотеку для простых чисел primesieve) и нужно каким-то образом скомпилировать внешний проект в своей Studio, чтобы воспользоваться его возможностями в своём приложении.
В противном случае, конечно же, нестандартный include вроде этого, который вы нашли в коде-образце
работать не будет ни за что.
Первым делом скачаем все исходники внешнего проекта "как есть" в архиве .zip, для этого у нас на гитхабе есть кнопка "Download ZIP":
Как загрузить проект с github в архиве .zip
Развернём проект, не создавая новой папки, если у вашего архиватора нет такого же пункта меню, просто сотрите предлагаемое архиватором имя новой папки, потому что папка уже есть в архиве:
Извлечь внешний проект из архива, не создавая новой папки
Если покопаться в файле readme.md проекта, как правило, можно найти инструкцию по установке (Build instructions) и даже "Detailed build instructions", где говорится, в числе прочего, и о компиляции проекта под Microsoft Visual C++:
Команды cmake для компиляции проекта со страницы документации
Откроем свой "некомпилируемый" без нужной библиотеки проект в Studio (я использую актуальную сборку версии 2019) и обратимся к команде меню Вид - Терминал. Выберем инструмент "Командная строка разработчика" (по умолчанию в новых сборках теперь выбран PowerShell, впрочем, если в документации приведены команды PowerShell, то применяйте их).
У Микрософта инструмент описан вот здесь.
Командная строка разработчика в Studio
В командной строке пишем команды из документации, но сначала, конечно, нужно перейти в ту папку, где у вас развёрнут скачанный проект. Мне понадобилось ввести в консоли следующее, завершая каждую команду нажатием Enter:
- теперь я в нужной папке, так как развернул свой архив в папку d:\temp
Далее как написано:
Можно просто копировать команды со страницы документации, в окне консоли вверху есть стандартная кнопочка "Вставить". А вот точка в записи команд имеет значение, это ссылка на текущую папку!
Ну и, конечно, для другой версии Studio будет другое указание компилятора, узнать своё можно командой
Нужный генератор будет помечен в списке "звёздочкой".
Теперь проект можно открывать в Studio и работать с ним, все нужные файлы есть в папке d:\temp\primesieve-master
Но мы хотим подключить всё, что нужно, к своему имеющемуся проекту, а не пытаться модифицировать чужую библиотеку.
- Меню Проект - Свойства, слева выбираем Свойства конфигурации, C/C++, Общие, раскрываем поле "Дополнительные каталоги включаемых файлов", говорим "Изменить" и показываем на папку D:\Temp\primesieve-master\include . В вашем проекте, как правило, тоже будет вложенная папка include .
- В том же окне выбираем Компоновщик - Общие - Дополнительные каталоги библиотек, "Изменить" и добавляем путь D:\Temp\primesieve-master\Release . Этого может оказаться мало, у вашего проекта и внешнего должны быть выбраны одинаковые конфигурации решения. Так как я выбрал Release для внешнего проекта, то и в своём проекте в списке "Конфигурации решения" (на стандартной панели инструментов) указал Release и платформу x64. Можно было работать и с Debug, но тогда и внешний проект компилируем как Debug и потом выбираем путь D:\Temp\primesieve-master\Debug .
- В списке C/C++ - Создание кода - Библиотека времени выполнения выбрал Многопоточный DLL (/MD), иначе будет "LNK2038: обнаружено несоответствие для 'RuntimeLibrary': значение 'MT_StaticRelease' не соответствует значению 'MD_DynamicRelease' в file.obj".
- Сам файл библиотеки, как правило имеющий тип .lib , тоже нужно прописать. Всё в том же окне свойства проекта выбираем список Компоновщик - Ввод, раскрываем список "Дополнительные зависимости", жмём "Изменить" и указываем в поле ввода имя файла библиотеки primesieve.lib
- На всякий случай, проверяем, что у нас в списке Компоновщик - Система - Подсистема, у меня там просто Консоль (/SUBSYSTEM:CONSOLE) , для других типов проектов может понадобиться изменение и этой настройки.
После этого у меня всё заработало.
Ну а конкретная задача, на которой я проверял библиотеку - печать самых длинных цепочек последовательных простых чисел, в которых разница между соседними значениями строго возрастает или строго убывает, предел счёта равен 1000000, вот сама программа:
Ответы вышли такие:
За счёт хорошо оптимизированного кода библиотеки считается всё мгновенно.
Читайте также: