Лучшая практика для многоцелевой библиотеки .NET

Я планирую выпустить библиотеку .NET с открытым исходным кодом (MIT).NET, но также включая библиотеки DLL, чтобы облегчить людям, чтобы они не могли сами скомпилировать все.

Моя библиотека очень упрощена в типах, которые она ссылается, единственная реальная зависимость, по-видимому, является .NET 3.0 или выше (поскольку она относится к Func<T> и тому подобное).

Я хочу, чтобы моя библиотека могла использоваться несколькими объектами, включая сервер .NET 4.0, сервер .NET 3.5, Windows Phone 7 Silverlight, обычный Silverlight, XNA (телефон), XNA (Windows) и XNA (XBox 360).

Я не буду использовать какие-либо типы, недоступные на платформах, на которые настроен таргетинг, например. HashSet<T> недоступен на Windows Phone 7, поэтому я не использую его.

Нужно ли мне создавать разные проекты и, следовательно, несколько DLL для каждой из этих целей или есть какой-то способ создать общую DLL для их использования?

ОТВЕТЫ

Ответ 2

Отдельные файлы проектов с общими общими исходными файлами - это путь. Убедитесь, что проекты настроены на сборку в разные выходные папки (например, не \bin\Debug, но \CF\bin\debug), чтобы предотвратить раздражения при использовании библиотеки из нескольких целей (например, проект на рабочем столе и устройстве).

OpenNETCF.IoC framework - пример этого - он поддерживает рабочий стол, CF, Windows Phone и MonoTouch с одинаковыми исходными файлами, но отдельные файлы проекта на платформу. Попытка скомпилировать одну бинарную сборку, которая может быть использована для всех из них, была слишком грязной и трудноподдерживающейся.

Главной причиной боли здесь является сохранение всех файлов проекта в синхронизации при добавлении/изменении файлов и обеспечении их полной компиляции. Сервер сборки может это сделать, если у вас есть доступ к автоматизации (который, к сожалению, Codeplex не раскрывает).

Ответ 3

Я делаю что-то подобное с библиотекой, которая предназначена для .NET и Silverlight. У меня есть один набор исходных файлов и отдельные файлы проектов, которые ссылаются на одни и те же общие файлы.

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

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

Если вы используете инструмент построения, такой как MSBuild или NAnt, вы можете создать сборку всех DLL для всех целевых платформ при запуске script.

Ответ 5

Я бы предложил библиотеку для каждой платформы. Позвольте мне объяснить.

Скажем, что полный .NET Framework включает в себя набор функций, которые не являются частью .NET Compact Framework, как тот, который вы можете найти с помощью Windows CE и смартфонов. Таким образом, чтобы полностью воспользоваться полной загрузкой возможностей каждой платформы, я бы использовал общую библиотеку с большим количеством интерфейсов, а затем реализовал эти интерфейсы в библиотеке классов .NET Framework platform specific, которая позволит вам полностью использовать преимущества над тем, что предлагается на определенной платформе.

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

Это, очевидно, важный аналитический и архитектурный вопрос, поскольку оба будут испытывать недостатки одной платформы над другой.

Вот как я буду действовать перед такой ситуацией:

  • Я бы исследовал различия между платформой .NET Framework;
  • Я бы отложил все (по мере необходимости) общие объекты, которые, по вашему мнению, вам могут понадобиться;
  • Я бы выделил различия, то есть объекты, которые вы можете использовать под одной платформой, но не другие;

Это органический анализ, который вам нужно будет выполнить, чтобы увидеть, что будет дальше.

То есть для какого-то подхода к водопаду.

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