У меня есть решение с несколькими проектами Wix, которые я хотел бы использовать Paraffin для ведения списка. включенных файлов.
Насколько я понимаю, вы обычно указываете Paraffin на различные папки bin, чтобы собрать все файлы.
Когда TFS создает решение, он переопределяет свойство OutDir msbuild, в результате чего все выходные данные сборки направляются в общий каталог Binaries, а не в папку bin каждого проекта.
Итак, как люди используют парафин в этом сценарии?
Я не использовал парафин уже много лет. Последняя версия может делать то, что вам нужно, но позвольте мне дать вам несколько дополнительных идей, которые вы можете использовать с парафином или без него.
Одним из недостатков парафина, тепла и жира является то, что они собирают бинарные файлы, которые, следовательно, должны существовать, находиться в соответствующие папки и т. д. Альтернативой является сбор данных из самого файла .sln и файлов .proj, на которые он ссылается. и отсутствуют в продукте|упаковке. Вы можете автоматически генерировать фрагменты для каждого двоичного файла во время сборки без необходимости поддерживать эти фрагменты в системе управления версиями и без необходимости фактического создания двоичных файлов.
Обратите внимание на интеграцию MSBuild с WiX 3.6+, особенно на цели урожая. Если это не работает для вас, попробуйте следующее:
Подход, который мы использовали в недавнем проекте, полностью обошел тепло. Мы написали действие рабочего процесса для сканирования .sln и его ссылок .proj и создания WiX Fragment напрямую для каждого двоичного файла — они все просто XML-документы. UUID версии 3 был сгенерирован на основе двоичного имени, целевой папки и версии сборки (кредит Derek Cicerone за эту идею), чтобы ComponentID были одинаковыми от сборки к сборке, но автоматически обновлялись при переходе на новую версию.
Некоторые двоичные файлы в решении (например, тестовые шаблоны) мы не хотели помещать в пакет установщика, поэтому мы внедрили новое свойство MSBuild в файл .proj, чтобы пометить его как «устанавливаемый» (или нет). Вы можете внедрить свойство для указания целевого каталога — в нашем случае все двоичные файлы должны были находиться в одной и той же папке, поэтому нам это не понадобилось. Вы даже можете создать собственную страницу свойств проекта Visual Studio для этого, если хотите пофантазировать.
Одним из преимуществ этого было то, что разработчики приложений в команде могли просто добавить в решение новый двоичный файл или удалить существующий, а пакет установщика автоматически синхронизировал то, что было в пакете .msi в тот момент, когда следующая сборка. Сэкономил установщику (искренне ваш) много хлопот!
Вы можете комбинировать эти подходы: сканировать решение, для которого оно создает двоичные файлы, а затем использовать эту информацию для нацеливания парафина или тепла на соответствующие папки|файлы для сбора.
