.Net Framework Setup-проект - организация обновлений

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

Как выяснилось, обновления для стандартных проектов .Net Setup Project - задача, требующая знания некоторых довольно тонких ньюансов.

Вообще, проблем при обновлении может быть несколько. Вот те, с которыми сталкивался я:

1. Уже установлена другая версия этого продукта (Another version of this product is already installed). Это самая часто встречающаяся проблема, впрочем, довольно легко разрешимая. Выглядит её основное проявление следующим образом:

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

• Увеличить свойство Version у Setup-проекта. К примеру, было 1.0.0, поставьте 1.0.1
• Сгенерить новый Product ID (студия 2010 сама предложит это сделать при изменении версии, в этом случае нужно просто ответить "Да").
• Выставить свойство Setup-проекта RemovePreviousVersions в True. По умолчанию оно False.

Ньюансы:

• Версии меньше 1.0.0 майкрософтовский установщик НЕ обновляет и не обрабатывает! 
• Четвертую цифру версии майкрософтовский установщик не учитывает. Т.е. 1.0.0.0 для него это то же самое, что 1.0.0.100500 :)
• Свойство Version в Setup-проекте - это версия именно установщика, она может быть вообще никак не связанной с версией программы.

2. Следующая проблема является следствием неполного решения предыдущей. Проявляется она в том, что новая версия программы успешно устанавливается, однако старая версия остается видна через Панель управления -> Программы -> Удалить программу.
Т.е., одновременно на одной машине как бы оказываются установленными две версии продукта.
Решение проблемы состоит в выполнении тех же пунктов, что и для первой проблемы (см. выше). Чаще всего, виновато не выставленное в True свойство RemovePreviousVersions.

3. Еще одна, очень противная проблема, - это когда всё нормально ставится, но при этом оказываются не замененными некоторые dll-ки и exe-шники. Очень противная проблема, которую мне посчастливилось обнаружить совершенно случайно ДО отправки пользователям. Всё дело, как выяснилось, в версиях устанавливаемых сборок.
Вспомним, когда мы создаем проект, для него генерируется файлик AssemblyInfo.cs, содержащий по умолчанию следующие строки:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Вот эти самые строки нужно обязательно заменить на другие:

[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

Вообще, инкремент версии может выполняться разными способами - макросами, аддонами, есть еще классный вариант с использованием MSBuild Community Tasks... Способ неважен, главное чтобы инкремент производился.
Между прочим, если ваши сборки используют StrongName-подписи, здесь могут выплыть дополнительные сложности, если ссылка на сборку прописана в каком-нибудь xml. Но уж тут выкручивайтесь сами...
Потому что Windows Installer обновлять сборки с одинаковыми версиями НЕ будет.

P.S. Между прочим, в разрешении описанных выше проблем мне очень помогли статьи и ответы на форумах некоего MVP по имени Phil Wilson. Настоящий эксперт в этой теме. Он даже написал про Setup-проекты и Windows Installer книжку, вот думаю, надо бы её прочитать...