Visual studio отличие собрать и построить
Презентацию к данной лекции Вы можете скачать здесь.
5.1. Проекты и решения в Visual Studio
Компилятор — это программа , которая преобразует высокоуровневые инструкции, создаваемые программистом, в инструкции более низкого уровня для выполнения на компьютере. В среде Microsoft . NET компилятор выдает код на промежуточном языке ( MSIL ), который при запуске программы компилируется в машинный код.
Эта команда скомпилирует файл MyProg.cs и создаст файл с именем MyProg.exe. Компилятор командной строки также доступен после установки Visual Studio .
Windows Phone SDK установит сразу все необходимые инструменты для создания приложений для Windows Phone : интерактивную среду разработки, эмулятор Windows Phone и другие инструменты. Инструменты также можно использовать для создания настольных приложений и игр XNA для компьютеров под управлением Windows и Xbox 360. Если в вашем компьютере установлена другая версия Visual Studio 2010, после установки Windows Phone SDK в нее будут добавлены новые типы проектов и инструменты.
Visual Studio . Visual Studio предоставляет единую среду для создания, редактирования и запуска программ. Она управляет проектами и решениями, которые объединяют все файлы программы, и позволяет управлять их содержимым. Также среда предоставляет инструменты для отладки программ. Visual Studio используется для создания приложений для компьютеров так же, как и для устройств Windows Phone .
После установки Windows Phone SDK значок Microsoft Visual Studio 2010 появится в списке программ.
Среда Visual Studio содержит большое количество кнопок, меню и инструментов, с которыми можно работать. Информацию об их назначении можно получить в справочной системе.
В рамках Visual Studio рассматриваются термины проект и решение . Они используются для организации создаваемых программ и систем. Visual Studio не может запустить любой код программы , который не входит в состав проекта или решения . Для начала можно использовать один из встроенных шаблонов для разных типов проектов.
Простой проект Visual Studio
Проект является контейнером для набора программных файлов и ресурсов , которые создают файл сборки. Самый простой проект содержит единственный файл программы. Можно создать проект , выбрав в главном меню Файл -> Создать проект …. Откроется диалоговое окно Создать проект (рис. 5.1).
Если выбрать шаблон Консольное приложение, Visual Studio создаст минимальный проект , который содержит единственный файл программы с именем Program.cs. Этот файл содержит примерно такой код:
Созданный файл Library.cs теперь является частью проекта , и при построении проекта Visual Studio скомпилирует этот файл вместе с файлом Program.cs. Однако, в результате будет создан единственный исполняемый файл с именем Program.exe. Поэтому только в одном из этих файлов может быть метод Main, иначе компилятор не сможет определить, какой из этих классов должен начать работу. Класс Library изначально будет пустым:
Можно создать экземпляры этого класса в методе Main:
Пространства имен и проекты. Классы Library и Program находятся в пространстве имен SimpleProject. Часто бывает удобно помещать различные части системы в отдельные пространства имен . Это особенно важно, если программы создают разные люди. Если программист, который пишет код библиотеки, решает, что имя Save подходит для создаваемого им метода, другой программист, который работает над другим модулем той же самой программы, также может использовать имя Save и для своего метода.
Пространства имен является логическим способом группирования элементов. У них нет никакой привязки к физическому расположению кода. Можно поместить класс библиотеки в отдельное пространство имен просто, просто изменив его имя:
Класс Library теперь находится в пространстве имен SimpleLibrary. Но попытка собрать проект приведет к возникновению ошибок (рис. 5.2).
увеличить изображение
Рис. 5.2. Окно с информацией об ошибках компиляции программы
Метод Main класса Program пытается создать экземпляр класса Library. Этот класс больше не находится в пространстве имен SimpleProject, и таким образом, возникают ошибки. К счастью, поле Описание списка ошибок подсказывает, что возможно пропущена директива using. Можно решить проблему, добавив директиву using, чтобы указать компилятору на необходимость просмотра пространства имен SimpleLibrary, если нужно найти класс:
Другой способ решения проблемы — использовать полностью определенные имена для получения доступа к ресурсам библиотеки:
Необходимо помнить о том, что мы просто создаем имена элементов в проекте , но не определяем, где они сохраняются. При построении проекта Visual Studio будет просматривать все исходные файлы проекта для поиска необходимых элементов.
Добавление ресурсов в проект
Если программа должна использовать ресурсы (например, изображение для заставки программы), их также нужно добавить в проект . Можно добавить растровое изображение таким же образом, как и новый класс. После добавления изображения оно появится в обозревателе решений (рис. 5.3).
Рис. 5.3. Список файлов проекта в обозревателе решений
Теперь решение содержит файл растрового изображения с именем Bitmap1.bmp. Можно выбрать способ управления этим содержимым в Visual Studio, изменив свойства этого объекта.
Свойства ресурсов . Как и у всех объектов, которыми управляет Visual Studio, у ресурсов проекта тоже есть свойства. Можно работать с свойствами ресурсов так же, как и со свойствами других объектов, — используя область свойств (рис. 5.4).
Представленные на рисунке настройки указывают Visual Studio при построении проекта скопировать изображение в тот же каталог, в котором создается файл с программой. В этом случае программа сможет открыть этот файл и использовать его при выполнении программы:
Этот код загрузит растровое изображение в переменную b класса Bitmap. Таким образом, можно легко добавлять в проект ресурсы .
Внедрение ресурсов в приложение. В предыдущем примере настройки указывают, чтобы рисунок был сохранен в том же каталоге, что и программа. Этот подход предполагает, что при установке программы файлы с изображениями будут скопированы в папку с исполняемым файлом программы.
Вместо этого можно встроить этот ресурс прямо в файл программы при ее построении. Когда программа будет создана, ее исполняемый файл будет содержать изображение. Это можно сделать, изменив свойства ресурса (рис. 5.5).
Рис. 5.5. Свойства изображения, внедряемого в исполняемый файл
Свойству Действие при построении файла Bitmap2.bmp присвоено значение Внедренный ресурс. Теперь изображение сохраняется внутри файла программы. Использовать этот ресурс немного сложнее, но будет гарантировано работать независимо от того, где программа установлена, поскольку при этом не используются дополнительные файлы:
Этот код загрузит изображение из встроенного ресурса и сохранит его в переменной b. Обратите внимание, что при получении ресурса из сборки кроме имени ресурса нужно также указать ее пространство имен .
Файлы сборки и исполняемые файлы
Сборки библиотек. Существуют два вида сборок — исполняемые файлы и библиотеки. При создании нового проекта можно выбрать шаблон для создания библиотеки. В этом случае будет создан новый проект , который будет содержать только классы библиотеки, т.е. никакой класс в сборке не будет содержать метод Main. Сборка библиотеки компилируется в файл с расширением .dll, что расшифровывается как динамически подключаемая библиотека . Классы библиотеки загружаются в памяти динамически во время работы программы.
Когда программа ссылается на метод класса библиотеке, этот класс будет загружен в память, и JIT-компилятор преобразует метод в машинный код, который сможет выполняться. Если класс вообще не используется, он не загружается в память. Использование динамических библиотек позволяет сохранить память за счет небольшой дополнительной работы при выполнении программы.
Динамические библиотеки можно использовать в других программах без необходимости использования исходного кода этих библиотек.
Рис. 5.6. Список ссылок проекта в обозревателе решений
Раздел Ссылки проекта содержит список всех ресурсов , которые использует приложение. При создании проекта определенного типа Visual Studio добавляет ссылки на ресурсы , которые требуются для построения проекта . Этим списком можно управлять самостоятельно. Например, для использования акселерометра в приложении для Windows Phone необходимо добавить ссылку на пространство имен Microsoft.Devices.Sensors.
Отметим, что при добавлении ссылки на ресурс он не обязательно станет частью проекта — сборка должна иметь возможность использовать этот ресурсу при работе. Если ресурс не будет доступен во время выполнения, то произойдет аварийное завершение работы программы. Ресурсы имеют номер версии. Если в систему будет добавлена новая версия библиотеки, любые более старые программы смогут использовать предыдущую версию.
В чем разница между простой перестройкой и сборкой Clean + Build в Visual Studio 2008? Отличается ли Clean + Build от выполнения Clean + Rebuild ?
Перестроить = очистить + построить (обычно)
Для решения с несколькими проектами «решение по перестройке» выполняет «очистку» с последующей «сборкой» для каждого проекта (возможно, параллельно). Принимая во внимание, что «чистое решение», за которым следует «решение для сборки», сначала очищает все проекты (возможно, параллельно), а затем строит все проекты (возможно, параллельно). Эта разница в последовательности событий может стать значительной, когда в игру вступают зависимости между проектами.
Все три действия соответствуют целям MSBuild. Таким образом, проект может переопределить действие Rebuild, чтобы сделать что-то совершенно другое.
То есть вы говорите, что Rebuild - это то же самое, что и Clean, за которым следует Build ? Это то, о чем я думал, но я не был уверен. За исключением Rebuild очищает и перестраивает каждый проект по одному. Clean + Build очищает их все, а затем строит все из них. В основном разница, если вы нажмете на нее случайно :) За исключением отсутствия гарантии, что они одинаковы. Смотрите ответ ДжаредПара ниже, который в сочетании с графом - это целая картина. Поскольку Rebuild выполняет каждый проект по очереди, у вас может быть «угловой случай», когда ваша информация о зависимостях испорчена, и вы получаете неупорядоченный проект сборки B, используя старый проект A, затем перестраивайте A, затем перестраивайте C. и т. Д. A полное решение Очистка с последующей полной сборкой решения поймает эту ситуацию, а перестройка - нет. Таким образом, чем более вы параноидальны и утомлены, тем больше вы должны отдавать предпочтение Clean, а затем Build. Это неправда. У меня был проект, в котором Clean + Build был успешным, и Rebuild вернул ошибки компиляции (циклические ссылки на файлы). Так что они не на 100% одинаковы.Эрл прав, что в 99% случаев Rebuild = Clean + Build.
Но они не гарантированы быть одинаковыми. 3 действия (перестроить, собрать, очистить) представляют разные цели MSBuild. Каждый из которых может быть переопределен любым файлом проекта для выполнения пользовательских действий. Таким образом, кто-то может полностью переопределить rebuild, выполнив несколько действий перед началом clean + build (или полностью удалить их).
Очень угловой случай, но указывающий на это из-за обсуждения комментариев.
Давайте определим реализацию Rebuild по умолчанию в терминах реализаций Clean и Build по умолчанию:
Для каждого проекта: перестроить проект = очистить проект + построить проект.
По решению: перестроить sln = foreach проект в sln (чистый проект + построить проект).
Обратите внимание, что из-за различий в порядке выполнения Rebuild sln отличается от (Clean sln + Build sln) = (foreach проект в sln Очистить проект) + (foreach проект в sln Build project). Кроме того, этот «foreach» может выполняться одновременно, поэтому разные задачи могут выполняться одновременно в двух сценариях.
Скажем, у вас есть sln, который содержит proj1, proj2 и proj3.
Перестроить sln = (Очистить proj1 + Построить proj1) & (Очистить proj2 + Построить proj2) & (Очистить proj3 + Построить proj3)
Clean Sln + Build Sln = (Очистить proj1 & Очистить proj2 & Очистить proj3) + (Создать proj1 & Build proj2 & Build proj3)
+ означает последовательный, & означает одновременный.
Поэтому, если зависимости проекта не настроены правильно, есть вероятность, что при выполнении Rebuild sln некоторые ваши проекты ссылаются на устаревшую библиотеку. Это потому, что не гарантируется, что все очистки будут завершены до начала первой сборки. Если вы выполните команду Clean sln + Build sln, они выдадут ошибку ссылки и немедленно сообщат вам об этом, вместо того, чтобы показывать вам приложение со странным поведением.
Это самый точный ответ, так как он объясняет, почему иногда я не мог восстановить, но смог очистить + построить.Сборка означает компиляцию и компоновку только исходных файлов, которые изменились с момента последней сборки, в то время как перестройка означает компиляцию и компоновку всех исходных файлов независимо от того, изменились они или нет. Сборка - это нормальное занятие, которое выполняется быстрее. Иногда версии целевых компонентов проекта могут быть не синхронизированы, и для успешной сборки требуется перестройка. На практике вам никогда не нужно чистить.
Build or Rebuild Solution строит или перестраивает все проекты в вашем решении, в то время как Build или Rebuild компилирует или перестраивает проект StartUp, "привет" на снимке экрана выше. Чтобы настроить проект автозагрузки, щелкните правой кнопкой мыши имя нужного проекта на вкладке «Обозреватель решений» и выберите «Установить как проект автозагрузки». Название проекта теперь выделено жирным шрифтом. Поскольку решения для домашних заданий обычно имеют только один проект, решение по сборке или перестроению фактически совпадает с решением по сборке или перестроению.
Компиляция просто компилирует исходный файл, который в данный момент редактируется. Полезно для быстрой проверки ошибок, когда остальные исходные файлы находятся в неполном состоянии, что помешает успешной сборке всего проекта. Ctrl-F7 - это сочетание клавиш для компиляции.
Как и Тоан Нгуен, я сталкивался с тем, что иногда решение Clean + Build успешно завершается в случае сбоя решения Rebuild (возможно, из-за межпроектных зависимостей), поэтому этот ответ вводит в заблуждение, по крайней мере, в 2018 году.Вообще-то, нет. они не равны.
Разница заключается в последовательности проектов, которые будут очищены и собраны. Допустим, у нас есть два проекта в решении. Очистка и последующая сборка будут выполнять очистку для обоих проектов, и затем сборка будет выполняться индивидуально, в то время как при восстановлении проект А будет получать и очищать, а затем строить после того, как этот проект Б будет очищен, а затем будет построен и так далее.
В отличие от простейших программ, таких как "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, вот сама программа:
Ответы вышли такие:
За счёт хорошо оптимизированного кода библиотеки считается всё мгновенно.
Читайте также: