В моем текущем проекте я делаю еженедельные релизы. Я использовал технику, описанную в эта почта, чтобы синхронизировать номера версий всех сборок в моем проекте. (В настоящее время у меня нет веских причин отслеживать номера версий сборок по отдельности, хотя я уверен, что этот день в конечном итоге наступит.)
Когда я выкладываю релиз, я создаю новую версию установщика. В отличие от всех сборок, номера версий которых можно получить из общего файла SolutionInfo.cs, номер версии установщика, насколько я могу судить, не является свойством сборки. Итак, мой процесс выпуска включает в себя ручное продвижение номера версии в проекте установки.
Или, я бы сказал, обычно включает в себя это. Я хочу превратить это во что-то, что я не могу облажаться. Я нахожу документацию по проектам установки и развертывания на удивление непрозрачной (было немного сложнее выяснить, как сделать возможным правильное удаление MSI, если пользователь установил его на путь, отличный от пути по умолчанию, то есть довольно чертовски распространенный вариант использования, который нужно недокументировать) и понятия не имею, возможно ли это вообще.
Любые идеи?
Редактировать:
Чтобы уточнить, я говорю о проекте установки и развертывания Visual Studio.





Это будет зависеть от набора инструментов установщика, который вы используете.
Мы используем TFS Team Build и WiX v3. У меня есть настраиваемая задача сборки, которая увеличивает номер сборки в Team build (например, 5.0.0.X), затем этот номер версии помещается в общее поле AssemblyInfo.cs AssemblyFileVersion. Он также передается MSBuild нашим решениям / проектам как свойство, которое затем передается в WiX и используется для обновления версии установщика.
Возможно, нам когда-нибудь понадобится улучшить управление версиями сборки, но сейчас это работает для нас очень хорошо.
CodeProject имеет сценарий для установки номера версии файла MSI, который можно запустить на предварительно созданном этапе проекта установки. Вы найдете это здесь:
Подробнее
Имейте в виду, что с установщиком Windows все немного сложнее. Файлы MSI (как и те, которые вы создаете с помощью проекта установки и развертывания VS) имеют не только номер версии, но и код продукта, который является значением GUID. Этот код продукта используется установщиком Windows для уникальной идентификации вашего продукта, например в Панели управления -> Добавить или удалить программы, где вы можете решить удалить или восстановить продукт.
Однако при изменении номера версии MSI этот код продукта также должен быть изменен в ряде случаев. Технология MSI плохо документирована, но вы можете найти некоторые рекомендации, когда также изменить код продукта на следующей странице MSDN: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx.
В своих проектах я всегда генерирую новый код продукта для каждой новой версии. Сценарий CodeProject также изменит код продукта за вас.
И еще одно: установщик Windows проверяет только первые три позиции номера версии afaik, все, что находится в четвертом месте, будет проигнорировано, т.е. 2.3.0.1234 считается равным 2.3.0.5678. (Версия продукта)
(На CodeProject есть соответствующая статья, которая также может быть вам интересна: http://www.codeproject.com/KB/install/VersionVDProj.aspx)
Я использую обходной путь для проектов установки VS2010 (.MSI + setup.exe). Откройте .vdproj в Блокноте и отредактируйте значение назначения ProductVersion (3.2.1 в примере ниже). Сохраните файл и запустите VS2010, дважды щелкнув файл .vdproj.
"Product"
{
"Name" = "8:Microsoft Visual Studio"
"ProductName" = "..."
...
"ProductVersion" = "8:3.2.1"
"Manufacturer" = "..."
...
}
Какое преимущество это дает по сравнению с простой установкой свойства Version в окне свойств проекта установки? Разве вы в любом случае не редактируете файл установочного проекта?
Мне не приходило в голову, что проблема может сводиться к программному обновлению файла проекта. Это сработает (хотя я уверен, что не буду использовать регулярные выражения для изменения XML). И спасибо за напоминание о коде продукта: VS напоминает вам об этом, но я бы забыл.