Нет кнопки сборка в 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".
При возникновении других проблем можно попробовать их загуглить, возможно, что кто-то уже сталкивался с ними и решил их.
Вероятно, между 25 и 50% случаев, когда я строю свое решение, я вижу это:
Моя проблема в том, что выходные окна ничего не говорят мне в тот момент, когда они зависают, и я не знаю, как еще определить причину этой блокировки. Если бы я догадался, я бы предположил, что это тупик в файловой системе или что-то в этом роде, но я не знаю, как это доказать - тем более, как предотвратить это.
Что я могу сделать, чтобы диагностировать и устранить это из моего решения, чтобы я больше никогда его не видел? В общем, как я могу диагностировать проблемы, возникающие во время сборки?
Если бы схожая проблема, VS зависал в течение примерно 45 секунд, затем собирался в течение 4 секунд и завершал работу. 45 секунд зависания не приведут к выводу GUI, а VS зависнет.
Используя ProcMon, я мог видеть более 3 миллионов операций с файлами в папке/packages/через devenv.exe, когда я собирался построить этот проект (и продолжу некоторое время после этого) !! Первые шаги сборки показывают, что он проверял КАЖДЫЙ ПАКЕТ на предмет необходимости восстановления пакета (это не так).
Поскольку я склонен винить во всем NuGet, я отключил восстановление пакета Nuget «разрешить NuGet загружать отсутствующие пакеты» в поле Visual Studio -> Параметры -> Диспетчер пакетов Nuget -> Общие. К моему удовольствию, сборка была очень быстрой. Всего 5 секунд!
Оказывается, у нас было включено восстановление пакетов при сборке (я думаю, что это включено по умолчанию сейчас в VS) И мы также проверили пакеты в системе контроля версий. Похоже, что это приводит к некоторому перебору TFS . проверка на восстановление пакета должна инициировать TFS для выполнения некоторых проверок работы системы контроля версий.
К вашему сведению, это было VS2013 ОБНОВЛЕНИЕ 4 - Nuget версия: 2.8.50926.663 .. на sln с NumberOfProjects = 38, но я мог бы воссоздать это зависание, просто создав один csproj с 2 зависимостями.
Локальный хост «Rebuild All» на Sln с SccNumberOfProjects = 53 занимал 7:05 с 2 минутами визуальной студии, замороженной/не отвечающей
- до 4:14 на 2-ядерном i5 без заморозки
- до 2:44 на 4-ядерном i7
Кроме того: это было на машине с различными инструментами безопасности наблюдателя файлов, вероятно, не увеличивающими скорость всего этого процесса . и, возможно, виноватыми.
Я видел это в больших проектах, когда MSBuild работает с включенным диагностическим переключателем. В Visual Studio перейдите в Инструменты/Параметры/Проекты и решения/Построить и запустить, а затем проверьте значение детализации выходных данных сборки проекта MSBuild. Если он не установлен как минимальный, попробуйте установить минимальный и посмотреть, смогут ли ваши сборки завершиться.
Похоже, что запуск Visual Studio в качестве администратора решил проблему для меня! (Для того, чтобы всегда запускать программу от имени администратора см. Как запустить Visual Studio от имени администратора по умолчанию )
Я обнаружил, что Visual Studio сильно зависает при создании больших проектов. Оказывается, это был ReSharper. После того, как я выключил его: Инструменты -> Параметры -> ReSharper -> Приостановить сейчас, все прекрасно работало без проблем (даже на очень больших решениях, более 100 проектов)
Было высказано предположение о том, что Microsoft Connect что проект зависел от зависаний. Я удалил проект моделирования из нашего решения и с тех пор не зависал (около недели).
В моем случае установка «максимальное количество параллельных сборок проекта» на 1 вроде помогла (т.е. сборка проекта из чистого состояния вызывает 1-минутное замораживание с последующей нормальной сборкой, и каждая последующая сборка работает нормально).
Вышеупомянутая настройка может быть установлена в Tool -> Options -> Projects and Solutions -> Build and Run .
Просто попробуйте команду ниже в режиме администратора. Перед запуском этой команды обязательно закройте все экземпляры VS.
Примечание: devenv находится в C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE.
Для меня это было связано с автоматической установкой пакета npm. Я пошел в Инструменты> Параметры> Проект и решения> Внешние веб-инструменты и снял флажки со всех внешних инструментов и перезапустил VS. После этого я смог построить его снова. Я знаю, что мне нужно проверить их, но мне нужно выяснить, что их вызывает и что не так с этим файлом решения.
Visual Studio 2017
Удаление Anaconda3 из установки исправило его. В procmon я видел сотни тысяч звонков в поисках файлов в папке Anaconda3 из сотен экземпляров powershell, порожденных msbuild.
В дополнение к ответу Феликса который решает (или почти решает) эту проблему для сборок:
Кроме проблемы во время сборки, у меня также была проблема с Консолью управления пакетами. Ожидание заняло около минуты. Используя procmon, я обнаружил, что папка репозитория NuGet анализировалась при каждом открытии этого окна (очень умно, Microsoft!). В этой папке было около 1000 пакетов. После удаления всего из вышеуказанной папки проблема с производительностью исчезла.
Обратите внимание, что мой ответ относится к VS 2015 (и может быть ниже). Я не проверял, но подозреваю, что в VS 2017 все должно быть в порядке.
Для меня проблема заключалась в расширении, которое автоматически запускает шаблоны T4 при сборке (AutoT4). Отключение при работе с решениями с EF решило проблему.
Блог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, вот сама программа:
Ответы вышли такие:
За счёт хорошо оптимизированного кода библиотеки считается всё мгновенно.
Вначале следует убедиться, что используемая вами редакция Visual Studio позволяет собирать 64-битный код. Если вы планируете разрабатывать 64-битные приложения с использованием последней версии (на момент написания курса) Visual Studio 2008, то следующая таблица поможет определить, какая из редакций Visual Studio вам необходима.
Таблица 1 - Возможности различных редакций Visual Studio 2008
Если ваша редакция Visual Studio позволяет создавать 64-битный код, то следует проверить, установлен ли 64-битный компилятор. На рисунке 1 показана страница устанавливаемых компонентов Visual Studio 2008, где не выбрана установка 64-битного компилятора.
Рисунок 1 - При установке не выбран 64-битный компилятор
Создание 64-битной конфигурации
Создание 64-битной конфигурации проекта в Visual Studio 2005/2008 - достаточно простая операция. Сложности будут подстерегать вас позже на этапе сборки новой конфигурации и поиска в ней ошибок. Для создания 64-битной конфигурации достаточно выполнить следующие 4 шага:
Шаг 1
Запускаем менеджер конфигураций, как показано на рисунке 2:
Рисунок 2 - Запуск менеджера конфигураций
Шаг 2
В менеджере конфигураций выбираем поддержку новой платформы (рисунок 3):
Рисунок 3 - Создание новой конфигурации
Шаг 3
Выбираем 64-битную платформу (x64), а в качестве основы выбираем настройки от 32-битной версии (рисунок 4). Те настройки, которые влияют на режим сборки, среда Visual Studio скорректирует сама.
Рисунок 4 - Выбираем x64 в качестве платформы и берем за основу конфигурацию Win32
Шаг 4
Добавление новой конфигурации завершено, и мы можем выбрать 64-битный вариант конфигурации и приступить к компиляции 64-битного приложения. Выбор 64-битной конфигурации для сборки показан на рисунке 5.
Рисунок 5 - Теперь доступна 32-битная и 64-битная конфигурация
Модификация параметров
Если вам повезет, то дополнительно заниматься настройкой 64-битного проекта, необходимости не будет. Но это сильно зависит от проекта, его сложности и количества используемых библиотек. Единственное, что стоит сразу изменить, это размер стека. В случае, если в вашем проекте используется стек размером по умолчанию, то есть в 1 мегабайт, есть смысл задать его размером в 2-3 мегабайта для 64-битной версии. Это не обязательно, но лучше заранее подстраховаться. Если у вас используется размер стека, отличный от размера по умолчанию, то есть смысл сделать его для 64-битной версии в 2-3 раза больше. Для этого в настройках проекта найдите и измените параметры Stack Reserve Size и Stack Commit Size (смотри рисунок 6).
Рисунок 6 - Расположение настроек проекта, задающих размер стека
Что дальше?
Создание 64-битной конфигурации проекта не означает, что проект будет компилироваться или, тем более, корректно работать. Процессом компиляции и обнаружением скрытых ошибок мы займемся в следующих уроках.
Читайте также: