Как экспортировать проект из visual studio

Обновлено: 07.01.2025

поэтому я работал над несколькими проектами, используя аудио и изображения из файлов в Visual Studio C++. На данный момент это всего лишь тестовые проекты, но теперь я собираюсь перейти к созданию 2D-игр для удовольствия, используя SFML и несколько разных аудиобиблиотек. Проблема в том, что я хочу раздавать свои игры другим, чтобы они могли играть и тестировать их, и я могу попытаться разработать какой-то мультиплеер для некоторых, тем самым увеличивая мое желание раздавать его другим, однако я не знаю, как я могу дайте им игры со всеми включенными файлами. Раньше я просто мог захватить exe-файлы из папки отладки или выпуска, но у этих проектов есть файлы, на которые они полагаются.

Итак, вот мой вопрос: Можно ли экспортировать exe-файл, содержащий все остальные файлы (wav, jpg и т. д.)? Если этот вопрос звучит в подавляющем большинстве глупо, тогда скажите мне, потому что я очень мало знаю, что такое exe, и может ли он содержать эти файлы (я привык к java, где u может просто экспортируйте что-то в runnable jar, и поскольку это архив, со всеми ресурсами, упакованными там, я не знаю, разделяет ли exe эти черты). Если это невозможно или есть лучшие альтернативы, то каковы они? Я видел вещи и знаю, как загружать звуки из массивов данных, было бы лучшим решением? Или есть другие варианты? Кроме того, в папке debug и release есть несколько DLL-файлов, которые мне нужно запустить проект, есть ли способ сжать они в exe или они должны быть в той же папке, что и exe, несмотря ни на что?

реальный вопрос: каков наилучший способ экспортировать exe-файл моего проекта, чтобы я мог использовать все свои звуковые и графические ресурсы, а также dll в легкую для распространения копию? Заранее благодарю за любые советы.

невозможно экспорт exe, которая содержит exe и несколько других файлов. Вы можете использовать установщик (например,помощи innosetup, который является бесплатным), или связывать дополнительные файлы в ресурс и загружать их из ресурса во время выполнения. (Первый имеет преимущество в том, что может спросить пользователя, где установить, создавать ярлыки и папки, пункты меню "Пуск" и т. д.).

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

бонус третий вариант вставлять файлы в ресурс и загрузка их во время выполнения или аналогичные вещи (можно получить действительно фантазии и объединить все файлы в один EXE, но это не совсем просто, и не очень желательно).

Как правило, каждая версия Visual Studio поддерживает большую часть типов проектов, файлов и других ресурсов предыдущих выпусков. С ними можно работать, как обычно, при условии, что вы не зависите от новых функций. В Visual Studio по возможности сохраняется обратная совместимость с предыдущими версиями, такими как Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. (См. заметки о выпуске, чтобы узнать, какие функции к какой версии относятся.)

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

В этой статье содержатся только сведения о типах проектов, которые Visual Studio 2017 может переносить. В статье не указаны типы проектов, которые больше не поддерживаются в Visual Studio 2017 и поэтому не могут быть перенесены. Кроме того, в ней не указаны поддерживаемые типы проектов, не имеющие проблем с миграцией. Этот список находится на странице целевой платформы и совместимости.

Если вы ищете сведения о последнем выпуске, см. версию этой страницы для Visual Studio 2022.

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

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2017, созданных в более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2017 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2017 автоматически вносит необходимые изменения в проекты кода (дополнительные сведения).

Как Visual Studio определяет необходимость переноса проекта

В каждой новой версии Visual Studio по возможности сохраняется совместимость с предыдущими версиями, чтобы проект можно было открывать, изменять и выполнять его сборку в разных версиях. Однако со временем неизбежны изменения, из-за которых некоторые типы проектов могут больше не поддерживаться. (Список типов проектов, поддерживаемых в Visual Studio 2017, см. в статье Целевые платформы и совместимость.) В таких случаях проект не будет загружаться в более новой версии Visual Studio и путь миграции предлагаться не будет. С проектом следует работать в предыдущей версии Visual Studio, которая поддерживает его.

В других случаях проект может открываться в более новой версии Visual Studio, но он должен быть обновлен или перенесен, из-за чего он может стать несовместимым с предыдущими версиями. Необходимость в миграции определяется в Visual Studio на основе ряда критериев:

совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;

совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2017, Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4, Visual Studio 2010 с пакетом обновления 1 (SP1)); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2017 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

нарушение совместимости с предыдущими версиями вплоть до Visual Studio 2013 RTM и с обновлением 5 из-за новых ресурсов времени разработки.

Технический владелец проекта оценивает эти критерии и создает запрос, если имеется необходимость в поддержке, обеспечении совместимости и миграции. Между версиями Visual Studio по возможности обеспечивается прозрачная совместимость. Это означает, что проекты, создаваемые и изменяемые в одной версии Visual Studio, будут работать в других версиях.

Однако если такая совместимость невозможна, как в случае с некоторыми типами проектов, описанными в этой статье, в Visual Studio открывается мастер обновления для внесения необходимых односторонних изменений.

Одним из этих односторонних изменений может быть изменение свойства ToolsVersion в файле проекта. Оно указывает, какая именно версия MSBuild может преобразовывать исходный код проекта в выполняемые и развертываемые артефакты. То есть несовместимость проекта с предыдущими версиями Visual Studio зависит не от версии Visual Studio, а от версии MSBuild, определяемой свойством ToolsVersion . Если ваша версия Visual Studio включает в себя цепочку инструментов MSBuild, соответствующую значению свойства ToolsVersion в проекте, то она может вызывать эту цепочку инструментов для сборки проекта.

С целью обеспечения максимальной совместимости с проектами, созданными в более ранних версиях, Visual Studio 2017 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли вообще Visual Studio 2017 данный тип проекта, как описано в статье Целевые платформы и совместимость.)

Следующие шаги

Дополнительные сведения см. в следующих статьях:

См. также

Каждая новая версия Visual Studio поддерживает большую часть типов проектов, файлов и других ресурсов. С ними можно работать как обычно, при условии, что вы не зависите от новых функций.

Если вы ищете сведения о следующем выпуске, см. версию этой страницы для Visual Studio 2022.

Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.

Текущее состояние проблем с миграцией см. в сообществе разработчиков Visual Studio. Просмотрите заметки о выпуске, чтобы узнать, какие функции к какой версии Visual Studio относятся.

Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2019 см. в статье Целевая платформа и совместимость для Visual Studio 2019.

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2019, созданных в более ранних версиях.

Visual Studio 2017: Формат XPROJ поддерживается исключительно для переноса в формат CSPROJ. При открытии XPROJ-файла вам будет предложено перенести файл в формат CSPROJ в стиле SDK. (Будет создана резервная копия XPROJ-файла.) Проекты формата CSPROJ в стиле SDK не поддерживаются в Visual Studio 2015 и более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.

Из установщика Visual Studio 2019 были исключены версии пакетов SDK Windows 10, предшествующие обновлению Windows 10 Fall Creators Update (сборка 16299). Вы можете вручную скачать старые версии таких пакетов SDK или использовать их более новые версии.

Миграция проекта

Хотя мы пытаемся сохранить совместимость с предыдущими версиями, существуют изменения, из-за которых некоторые типы проектов могут больше не поддерживаться. (Список типов проектов, поддерживаемых в Visual Studio 2019, см. в статье Целевые платформы и совместимость.) В таких случаях в более новой версии Visual Studio не будет загружаться проект или предлагаться путь миграции. С этим проектом необходимо будет работать в предыдущей версии Visual Studio.

Иногда проект может открываться в более новой версии Visual Studio, но он должен быть обновлен или перенесен, из-за чего может стать несовместимым с предыдущими версиями. Необходимость в миграции определяется в Visual Studio на основе ряда критериев:

совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;

совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2019, Visual Studio 2017; Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4, Visual Studio 2010 с пакетом обновления 1 (SP1)); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2019 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

Группа разработчиков проекта оценивает эти критерии и создает запрос, если есть необходимость в поддержке, обеспечении совместимости и миграции. Мы пытаемся обеспечивать совместимость между версиями Visual Studio, чтобы проекты, создаваемые в одной версии Visual Studio, могли работать и в других версиях.

Иногда такая совместимость невозможна. Тогда в Visual Studio открывается мастер обновления для внесения необходимых односторонних изменений. Одним из этих односторонних изменений может быть изменение свойства ToolsVersion в файле проекта. Оно указывает, какая именно версия MSBuild может преобразовывать исходный код проекта в требуемые выполняемые и развертываемые артефакты.

Несовместимость проекта с предыдущими версиями Visual Studio зависит не от версии Visual Studio, а от версии MSBuild, определяемой свойством ToolsVersion . Если ваша версия Visual Studio включает в себя цепочку инструментов MSBuild, соответствующую значению свойства ToolsVersion в проекте, то она может вызывать эту цепочку инструментов для сборки проекта.

С целью обеспечения совместимости с проектами, созданными в предыдущих версиях, Visual Studio 2019 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли Visual Studio 2019 данный тип проекта, как описано в статье Целевая платформа и совместимость для Visual Studio 2019.)

Следующие шаги

Дополнительные сведения см. в следующих статьях:

См. также

Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.

Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2022 см. в статье Целевая платформа и совместимость.

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2022, созданных в более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.

Миграция проекта

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

совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;

совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2022, Visual Studio 2019; Visual Studio 2017, Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4 и Visual Studio 2010 с пакетом обновления 1); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2022 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

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

Есть ли в VS инструмент для этого? Я использую VS 2008

Если вам нужна копия, самый быстрый способ сделать это - сохранить проект. Затем сделайте копию всего этого в файловой системе. Вернитесь в Visual Studio и откройте копию. Оттуда я, скорее всего, порекомендую переименовать проект / решение, чтобы у вас не было двух с одинаковыми именами, но это самый быстрый способ сделать копию.

GUID проекта обновляется VS автоматически, если в том же решении существует другой проект с таким же GUID. Я пытаюсь это сделать, но он не переименовывает пространства имен приложений. Не то, что я искал. GUID проекта НЕ ОБНОВЛЯЕТСЯ АВТОМАТИЧЕСКИ VS in Community 2017 Версия 15.8.4. На самом деле, как это могло быть, если ваш AssemblyInfo.cs находится в управлении исходным кодом?

В вашем проекте выберите: Project - Export Template

Мастер позволит вам определить

Имя Шаблона
Описание шаблона
Икона
Предварительный просмотр изображения

Затем он архивирует ваш проект в каталог «Мои экспортированные шаблоны». У вас также есть возможность сделать ваш шаблон доступным при создании нового проекта.

Когда вы используете свой шаблон для создания нового проекта, пространство имен будет правильным для 'your_new_project_name' во всех файлах, все ссылки правильные, все идеально :)

ПРИМЕЧАНИЕ.
Если в вашем проекте есть пустая папка, она НЕ будет добавлена в шаблон, поэтому я просто добавил пустой класс, соответствующий каждой папке, и образец изображения для папки изображений.

В VS2017 шаблон экспорта находился в пункте меню верхнего уровня Project. Это невероятно полезно, как я не знал об этом раньше? Благодарность! Это должен быть выбранный ответ. Очень просто! Этот процесс также должен был скопировать его в вашу папку Templates \ ProjectTemplates, просто убедитесь. Мне пришлось перезапустить Visual Studio, чтобы увидеть это в диалоговом окне создания проекта. Когда пришло время импортировать шаблон для создания нового проекта, я не мог понять, как это сделать. Оказалось, что мне пришлось использовать панель поиска в диалоговом окне «Новый проект», чтобы найти шаблон.

Думаю, если это то, что вы делаете часто, есть небольшая (платная) утилита, которая обещает сделать это за вас: я не использовал ее, поэтому не уверен, насколько она хороша:

На CodePlex также есть этот проект:

Я, вероятно, попробую проект codeplex, и если он не сработает, я вручную все переименую и отредактирую файл sln.

Крайне НЕ РЕКОМЕНДУЕТСЯ копировать проекты вообще, потому что некоторые файлы конфигурации сформированы внутри, например .csproj, .vspscc и т. Д., Могут (и, скорее всего, будут) указывать на ссылки, которые относятся к местоположению предыдущих решений и другим путям / местоположениям в системе или TFS. Если вы не являетесь экспертом в чтении этих файлов и исправлении ссылок, не пытайтесь копировать проекты.

Вы можете создать скелетный проект того же типа, который собираетесь скопировать, при этом будут созданы правильные файлы .csproj, .vspscc . Теперь вы можете свободно копировать файлы классов, скрипты и другой контент из предыдущего проекта, поскольку они не повлияют. Это обеспечит плавную сборку и контроль версий (если вы захотите в этом заинтересоваться)

Сказав все это, позвольте мне дать вам метод пошагового копирования проекта:

В обозревателе решений перейдите к проекту, который хотите скопировать, и щелкните правой кнопкой мыши .
Теперь выберите « Открыть папку в проводнике » (если у вас есть решение, сопоставленное с локальным путем на вашем диске).
Выберите проекты, которые вы хотите реплицировать как целые папки (вместе со всеми зависимостями, файл bin .vspscc, файл .csproj)
Вставьте их в желаемое место (это может быть та же папка решения или даже другая папка решения. Если она находится в той же папке решения, вам потребуется переименовать ее, а также .csproj и другие внутренние файлы на новое имя. ).
Не возвращайтесь в Visual Studio, щелкните правой кнопкой мыши «Решение»> «Добавить»> «Существующий проект» .
Найдите и выберите файл проекта (файл .csproj) в том месте, где вы его разместили, и выберите « открыть ».
Теперь этот файл появится в обозревателе решений, чтобы вы могли работать.

Обновление: лучший ответ по состоянию на 2019 год - это тот, который ниже @Shane. Создание шаблонов VS - идеальный способ клонировать проекты без проблем со ссылками.

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

Как я могу экспортировать весь проект Visual Studio? Я хочу получить копию non-source-controlled на моем локальном жестком диске.

Я родом из SVN-го фона и только что попал в TFS-й. В Tortoise SVN я бы использовал для этого команду export all - я бы щелкнул Правой Кнопкой Мыши каталог проекта, перетащил его в другой каталог и выбрал "Export all".

2 ответа

Я скачал nuget.exe и попробовал установить. Я хотел бы нацелиться на проект Visual Studio, чтобы он добавлял ссылку в командную строку за пределами Visual Studio. Это просто загрузка пакета с номером версии на конце. MyOutputDirectory-это выходной каталог, в котором есть решение Visual studio.

Как мне экспортировать проект в Android Studio? Я имею в виду, как я обычно делал в Eclipse по File|Export ..

На случай, если кто - то еще столкнется с этим вопросом-подумайте о функции SVN "Export".

"Get latest" в новое/отдельное рабочее пространство, по-видимому, является лучшим решением, встроенным в TFS.
См. Этот вопрос: TFS Получить конкретную версию в отдельную папку

Можете ли вы получить последнюю версию своего проекта, а затем сделать то же самое? перетащите каталог в другое место на диске? Вы также можете открыть решение и выбрать Файл -> Изменить систему управления версиями, чтобы отключить ее от системы управления версиями в ее текущем расположении.