Сценарии сборки VS2010 для упаковки DLL в MSI и регистрации в GAC - PullRequest
6 голосов
/ 15 января 2012

У меня есть требование упаковать и выпустить библиотеку элементов управления .NET на нескольких платформах, и у меня есть вопрос о том, как автоматизировать это развертывание (или сделать его максимально эффективным) с помощью сценариев сборки и конфигураций VS2010.

Библиотека управления должна быть выпущена как версия Silverlight (отдельные сборки для SL 3.0, 4.0, 5.0) и версия WPF (отдельные сборки для .NET3.5 / .NET4.0).Мне также нужно указать версии выпуска и пробные версии тех же библиотек.Пробные версии будут дифференцированы в коде с помощью оператора препроцессора TRIAL.Пробная и полная версии будут скомпилированы в режиме RELEASE.

Мне интересно, как этого добиться наиболее эффективным способом.Мое решение VS2010 в настоящее время имеет один проект для WPF (.NET 4.0) и один отдельный проект для SL (SL 4.0).

  • Нужно ли создавать дополнительные проекты csproj для отсутствующих версий, например .NET 3.5 и SL 3.0 и 5.0?
  • Я хочу создать один MSI для всех DLL-библиотек Silverlight и одинMSI для всех библиотек WPF.Нужно ли создавать дополнительные MSI для версий, скомпилированных как Trial?Как насчет отдельных MSI для каждой версии .NET или Silverlight Framework?
  • Можно ли достичь описанного выше пакета развертывания, используя build.targets или сценарии сборки?

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

Наконец, при перераспределении управляющих библиотек установка в идеале должна привести к регистрации в GAC.

Любые комментарии / предложения приветствуются.

С уважением,

Ответы [ 2 ]

2 голосов
/ 15 января 2012

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

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

Я считаю, что вы должны иметь возможностьчтобы выполнить все ваши потребности в одном проекте installshield, используя различные ключи и ключи конечного пользователя (для запуска пробной или реальной установки), но вы можете рассмотреть возможность разделения пробной и реальной в зависимости от вашей схемы лицензирования.

Обновление

Вы также можете решить эту проблему с помощью чистого решения VS2010, оно просто более сложное.

Исходя из ваших целей, вам потребуется всего 5 проектов иКаждое решение будет иметь 2 конфигурации, одну для выпуска, одну для пробной версии (гдеопределение eprocessor установлено).

Возможно, вам удастся обойтись без единого решения по сборке, которое содержит все 5 проектов, поскольку вы можете ссылаться на выходные данные каждого проекта отдельно в рамках проекта установки VS.

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

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

Один очень важныйобратите внимание, что я только что вспомнил, как набирал выше: в какой-то момент (возможно, это было исправлено) было невозможно построить проекты установки Visual Studio 2010 через MSBuild, поэтому мы пошли на сборку через devenv.com.

0 голосов
/ 24 января 2012

Ради потомков я записываю решение, которое придумала благодаря очень информативному ответу tims_tech .

Решено с использованием командного файла msdos следующим образом.

  • Скинул идею #If Trial switch. Вместо этого компонент лицензируется по файлу licx, поэтому пробная сборка аналогична сборке выпуска. Это означает только одно решение для работы разработчика, выходные данные которого получены из
  • Создание пакетного файла для перестройки выходных проектов Silverlight и WPF с помощью MSBuild, переключение инструментов для создания нескольких версий
  • Скопированные библиотеки DLL в структуру каталогов в стиле Nuget, например Сборка / lib / net40, сборка / lib / sl4, сборка / lib / sl5 и т.д ...
  • Обфусцировать построенных библиотек на месте
  • Примеры проектов XCopy для Build / examples /
  • Используйте Powershell для редактирования примеров проектов, чтобы ссылаться на новые запутанные результаты.

Для справки см. Следующие вопросы и ответы по удалению / повторному добавлению ссылок и редактированию файлов проекта с powershell

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...