Как запрограммировать три издания Light, Pro, Ultimate в одном решении - PullRequest
Новая
       28

Как запрограммировать три издания Light, Pro, Ultimate в одном решении

8 голосов
/ 31 мая 2010

Я хотел бы знать, как лучше всего запрограммировать три разных редакции моего приложения на C # ASP.NET 3.5 в VS2008 Professional (который включает в себя проект веб-развертывания). У меня есть версия приложения Light, Pro и Ultimate (или версия). На данный момент я поместил все в одно решение с тремя версиями сборки в диспетчере конфигурации и использую директивы препроцессора по всему коду (около 10 таких конструкций в десяти тысячах строк кода, так что его можно наблюдать): 

#if light
//light code
#endif
#if pro
//pro code
#endif //etc...

Я часами читал в stackoverflow и думал о том, как, например, Microsoft делает это с разными версиями Windows, но не нашла того, чего я ожидала. Где-то идет интенсивное обсуждение того, являются ли директивы препроцессора злыми.

Что мне нравится в этих директивах if:

  • параллельный код различий, поэтому я пойму код для разные издания через шесть месяцев
  • и особая выгода НЕ давать скомпилированный код других версий клиенту.

ОК, длинная экспликация, повторный вопрос: Какой лучший путь?

Ответы [ 3 ]

7 голосов
/ 31 мая 2010

У меня будет соблазн управлять разницей во время выполнения с разными лицензиями и включать / отключать функции с использованием этой конфигурации. Почему?

  1. вам нужно построить только один развертываемый.
  2. Вы можете тестировать это гораздо проще, чем собирать 3 версии и проверять это.
  3. пользователи могут обновить и просто отправить новую лицензию. Им не придется обновлять / переустанавливать.

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

2 голосов
/ 31 мая 2010

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

Вы потеряете «параллельный» код, но имхо, это просто создает сложные методы, а не обслуживаемый код. Используйте методы расширения, если вы хотите предоставить больше функциональности для типа или получить классы.

0 голосов
/ 31 мая 2010

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

затем вы создаете сборку облегченной / профессиональной / окончательной редакции, которая переопределяет эти методы.

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

здесь вы можете работать с внутренним средством доступа и сделать внутреннюю сборку кода видимой для сборок издания

...