Как сохранить номер версии установщика в синхронизации с номерами версий установленных сборок?

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

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

Или, я должен сказать, обычно включает в себя выполнение этого. Я хотел бы превратить это во что-то, что я не могу испортить. Я считаю, что документация по проектам установки и развертывания на удивление непрозрачна (было довольно сложно узнать, как сделать возможным MSI для правильной деинсталляции, если пользователь установил его на путь, отличный от стандартного, довольно бесполезный общий случай использования, чтобы быть недокументированным) и не имеют понятия, возможно ли это сделать.

Любые идеи?

Edit:

Просто для уточнения, это проект установки и развертывания Visual Studio, о котором я говорю.

Ответ 1

CodeProject имеет script, чтобы установить номер версии файла MSI, который вы могли бы запустить на предварительно построенном этапе проекта установки. Вы найдете его здесь:

http://www.codeproject.com/KB/install/NewSetupVersion.aspx

Подробнее

Помните, что с установщиком Windows вещи немного сложнее. Файлы MSI (как тот, который вы создаете с помощью проекта установки и развертывания VS) имеют не только номер версии, но и код продукта, который является значением GUID. Этот код продукта используется установщиком Windows для уникальной идентификации вашего продукта, например. в панели управления → Добавить или удалить программы, в которых вы можете решить удалить или восстановить продукт.

Однако при изменении номера версии MSI этот код продукта также должен быть изменен в ряде случаев. Технология MSI плохо документирована, но вы можете найти некоторые рекомендации, когда также изменить код продукта на следующей странице MSDN: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx.

В моих проектах я всегда создаю новый код продукта для каждой новой версии. script в CodeProject также изменит код продукта для вас.

И еще одно: установщик Windows проверяет только первые три места номера версии afaik, что-то в четвертом месте будет проигнорировано, т.е. 2.3.0.1234 считается равным 2.3.0.5678. (ProductVersion)

(Связанная с вами статья о CodeProject также может быть вам интересна: http://www.codeproject.com/KB/install/VersionVDProj.aspx)

Ответ 2

Его будет зависеть от используемого вами инструментария установщика.

Мы используем сборку TFS Team и WiX v3. У меня есть пользовательская задача сборки, которая увеличивает номер сборки в Team build (например, 5.0.0.X), затем этот номер версии переносится в общее поле AssemblyInfo.cs AssemblyFileVersion. Он также передается MSBuild нашим решениям/проектам в качестве свойства, которое затем передается в WiX и также используется для обновления версии установщика.

Нам также, вероятно, нужно будет лучше справляться с версией сборки, но сейчас это работает очень хорошо для нас.

Ответ 3

Я использую обходной путь для проектов установки VS2010 (.MSI + setup.exe). Откройте .vdproj в Блокноте и отредактируйте значение назначения ProductVersion (3.2.1 в приведенном ниже примере). Сохраните файл и запустите VS2010, дважды щелкнув файл .vdproj.

    "Product"
    {
    "Name" = "8:Microsoft Visual Studio"
    "ProductName" = "..."
...
    "ProductVersion" = "8:3.2.1"
    "Manufacturer" = "..."
...
    }