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

Question

Я планирую выпустить библиотеку .NET с открытым исходным кодом (MIT), а также включить библиотеки 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 для них всех?

Answer 1

В этом году на PDC говорили о таких вещах:

Это видео и это слайды .

Answer 2

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

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

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

Answer 3

Посмотрите на расширение Portable Library Tools (Последнее обновление: 17.06.2011) от BLC Team (Microsoft) и это введение Статья MSDN (Последнее обновление: август 2011 г.).

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

---

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