Do NOT оставить прежним PackageCode .
Вы действительно хотите, чтобы это автоматически генерировалось ... см. Документацию:
Неидентичные .msi файлы не должны
иметь тот же код пакета. это
важно изменить код пакета
потому что это основной идентификатор
используется установщиком для поиска
и проверить правильность пакета для
данная установка. Если пакет
изменилось без изменения пакета
код, установщик не может использовать
более новый пакет, если оба еще
доступно для установщика.
Вот пример из нашей производственной среды ...
<Product Id="*"
UpgradeCode="$(var.Property_UpgradeCode)"
Name="!(loc.ApplicationName)"
Language="!(loc.Property_ProductLanguage)"
Version="$(var.version)"
Manufacturer="!(loc.ManufacturerName)" >
<Package Description="!(loc.Package_Description) $(var.version)"
Comments="!(loc.Package_Comments)"
Manufacturer="!(loc.ManufacturerName)"
InstallerVersion="301"
Compressed="yes"
InstallPrivileges="elevated"
InstallScope="perMachine"
Platform="$(var.ProcessorArchitecture)" />
Теперь недостатком этого подхода является то, что вы, вероятно, также хотите применить крупные обновления, которые заботятся только о ссылках на код обновления. Теперь мы можем воспользоваться тем, что для пакетов установщика Windows важны только первые три поля, например 1.0.0.1 и 1.0.0.2 оба интерпретируются как 1.0.0 (это явно упоминается в документации, поэтому мы можем положиться на него.)
Расширяя эту логику, мы можем автоматически увеличивать (игнорируемое) поле четвертой версии с каждой сборкой, но предотвращать обновление, когда первые три совпадают.
<UpgradeVersion Property="ANOTHERBUILDINSTALLED"
Maximum="$(var.version)" Minimum="$(var.version)"
IncludeMinimum="yes" IncludeMaximum="yes" OnlyDetect="yes" />
Плюс в том, что это полностью прозрачно для клиентов, но не позволяет внутренним командам тестирования / контроля качества устанавливать одну «сборку» поверх другой, и вам также необходимо убедиться, что сразу после любого публичного выпуска вы вручную увеличиваете один из первых трех. поля версии.