Кошмарный дистрибутив проекта с открытым исходным кодом Visual Studio

Question

Каждый раз, когда Microsoft выпускает новую версию visual studio, они всегда требуют, чтобы я преобразовал файлы моего решения и проекта в «последнюю версию». Даже с таким простым решением, как «Hello World», мне нужно пройти через мастер их преобразования!

И, что еще хуже, новые файлы решений Visual Studio несовместимы со старыми версиями Visual Studio.

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

Есть ли какой-нибудь хороший способ распространения проекта Visual Studio и позволяющий людям, использующим более старые версии Visual Studio, по-прежнему использовать его? Это простая программа на C, не использующая изящные опции. У меня есть доступ только к Visual Studio 2008, и Visual Studio не предоставляет мастера обратного преобразования. Имеет ли смысл выпускать исходный код, используя nmake + makefile для сборки программы? Кажется, что формат файла nmake существенно не изменился за некоторое время, и было бы возможно предоставить make-файл, который работает с более широким диапазоном версий visual studio.

Answer 1

Обычный способ сделать это - поместить файлы проекта vs в подкаталоги решения. Например,

solution
 - build
 -- vc6
 -- vc7
 -- vc8
 -project1
 -- src
 -- build
 --- vc6
 --- vc7
 --- vc8
 -project2
 -- src
 -- build
 --- vc6
 --- vc7
 --- vc8

Тогда, когда вы получите новую версию против - скопируйте последний каталог проекта, например, vc7 в vc8 - сделать то же самое для решения - открыть решение и файлы проекта в текстовом редакторе, чтобы исправить любые пути - наконец, откройте решение в новой версии VS и дайте ему преобразовать ваши проекты - (Используйте управление исходным кодом, как будто один или ваши пути неверны, чтобы обновить проект в старом каталоге)

Это утомительно, но делать это нужно только раз в несколько лет.

Это то, как мы привыкли это делать, но есть и лучший способ - использовать CMake для генерации ваших проектов. Мы используем это сейчас в работе, и это позволяет использовать одно определение проекта для работы с Windows и Unix. В Windows мы используем проекты против Unix, мы используем Eclipse и Makefiles. Также CMake позволяет вам абстрагировать общие параметры проекта, такие как флаги компилятора и компоновщика, поэтому их нужно изменять только в одном месте.

Теперь я использую CMake для всех проектов c ++ независимо от того, требуются ли мне его мультиплатформенные возможности.

Answer 2

Вы можете использовать CMake в качестве инструмента сборки для вашего проекта. Он будет генерировать файлы проекта VS для вас, и вы можете просто открыть файл и использовать его для создания проекта. Проблемы с конвертацией не будут иметь значения, потому что вы можете просто использовать CMake, чтобы собрать его заново.

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

Answer 3

Простого ответа нет. Хотелось бы, чтобы мы это сделали. Ситуация только усугубляется тем фактом, что с 2005 года вам также необходимо упаковать его в Redist Pack или сделать статическую связь со средой выполнения. И я не имею ни малейшего представления о том, что он будет делать, если у вас есть статический бинарный файл 2008, говорящий с приложением более раннего поколения (ранее 2005 года). По словам М.С., это должно работать.

Можете ли вы предположить, что у всех ваших пользователей будет копия Visual Studio? И все они работают под одной версией? (Я знаю, что экспресс-издание в настоящее время бесплатное ...) Вам нужно будет проинформировать свою базу пользователей о трудностях, если вы продолжите идти по этому пути и попросите их всех использовать одну и ту же версию VS2008, чтобы облегчить жизнь всем вокруг.

Я бы лучше использовал make / gcc, чем ходить по парку.

Answer 4

Одним из решений, которое я видел в коммерческих библиотеках Windows, является присвоение имен файлам решений с версией VS в качестве суффикса (например, Project_VS2005.sln, Project_VS2008.sln и т. Д.). Вы по-прежнему должны синхронизировать их, но вам не нужно изменять пути к файлам, включать каталоги или значительно изменять файлы фактических решений; просто сохраните несколько файлов, по одному для каждой версии VS, которая поддерживается. Вы должны сделать то же самое для файлов проекта, но, по крайней мере, вам не нужно менять содержимое для поддержки различных структур каталогов, если вы не хотите поддерживать параллельное построение с несколькими версиями VS, и в случае где вам нужно только изменить настройки вывода для каждого отдельного файла проекта.

Не сказать, что это отличное решение, а просто еще один вариант.

Answer 5

Я бы предложил вам использовать процесс с открытым исходным кодом. Выпустите свой код как VS 2008 и разрешите кому-нибудь, кто использует более ранние версии, предоставить файл решения для этих версий. Это способ с открытым исходным кодом.

Answer 6

Я думаю, что использование nmake - это путь, к сожалению, VC6 - последняя версия, которая автоматически создаст ее для вас на основе проекта.

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