Убедитесь, что необходимые действия по установке для DLL выполняются без дублирования кода - PullRequest
4 голосов
/ 05 октября 2011

У меня есть решение на c # с двумя обычными проектами и проектом установки. Один из обычных проектов - это исполняемый файл, а другой - dll, который я также использую в других решениях. Проект dll полагается на наличие определенного источника журнала событий, в который он может войти, и поскольку программа предназначена для запуска пользователями, которым не разрешено создавать источники журналов, этот источник должен быть создан при установке.

Я сделал это, создав класс установщика для моего исполняемого проекта, создав источник журнала в установщике и включив этот установщик в свои пользовательские действия в проекте установки. Это работает, но теперь мне нужно создать аналогичный установщик для любого другого проекта, который также использует эту DLL.

Лучшее решение было бы, если бы я мог написать установщик для dll, а затем выбрать dll для пользовательских действий в проекте установки. Таким образом, мне нужно будет указать требование создания журнала только один раз. Однако я не могу выбрать выход проекта dll для пользовательских действий в проекте установки.

Еще одним хорошим решением было бы, если бы я мог как-то указать, что установщик для исполняемого файла должен быть транзитивным, чтобы он также выполнял действия по установке для любых проектов, от которых зависел исполняемый проект, но я не знаю, как это сделать. укажите это требование.

Так, что я могу сделать, чтобы избежать дублирования кода установки между различными проектами?

Ответы [ 3 ]

1 голос
/ 13 октября 2011

У меня просто есть сборка MyApplication.Installation, в которую я помещаю настраиваемое действие, которое создает источник события.Все мои проекты установки ссылаются на эту сборку и вызывают ее пользовательское действие.

1 голос
/ 13 октября 2011

Как насчет этого? Вы создаете простой пакетный файл или сценарий powershell для создания файла журнала, который вы хотите создать. Вы можете сделать установщик для файла dll (или даже всего решения, это не имеет значения.) Затем вы можете вызвать пакетный файл. что вы только что написали из установщика. [См. здесь] . Таким образом, вы не дублируете логику создания зависимых файлов / ресурсов; и вы можете использовать один и тот же пакетный файл для нескольких проектов установки в основном (при условии, что они используют одни и те же ресурсы.)

Надеюсь, это ответит на ваш вопрос. На шаг впереди, в какой среде находятся ваши клиенты? Они все еще на Win XP (SP2 или раньше)? Если это так, вы должны сделать что-то похожее на то, что вы уже имели в виду. Однако, если это не так, если ваши клиенты используют Win 7, вы можете использовать nuget для публикации своих корзин (см. здесь ). Я признаю, что это все еще рассматривается как решение для обмена исходным кодом. Но я считаю, что этот подход можно распространить и на публикацию двоичных файлов.

1 голос
/ 13 октября 2011

Вы должны иметь возможность добавить класс установщика в вашу DLL, а затем зарегистрировать DLL для выполнения пользовательских действий в проекте установки.Если вы попробовали это и столкнулись с проблемами, не могли бы вы более точно указать, какую версию Visual Studio и какой тип проекта установки вы используете?

...