servicios - La mejor práctica para una biblioteca.NET de múltiples objetivos

proyectos para bibliotecas publicas

Question

Estoy planeando lanzar una biblioteca .NET de código abierto (MIT), pero también incluir archivos DLL para facilitar la tarea de las personas para que no tengan que compilar todo ellos mismos.

Mi biblioteca es muy simplista en los tipos a los que hace referencia, la única dependencia real parece ser .NET 3.0 o superior (ya que se refiere a Func<T> y similares).

Quiero que mi biblioteca sea utilizable por múltiples objetivos, incluido el servidor .NET 4.0, el servidor .NET 3.5, Windows Phone 7 Silverlight, Silverlight normal, XNA (teléfono), XNA (Windows) y XNA (XBox 360).

Me aseguro de no utilizar ningún tipo que no esté disponible en las plataformas a las que me dirijo, por ejemplo, HashSet<T> no está disponible en Windows Phone 7, así que no lo estoy usando.

¿Tendré que hacer diferentes proyectos y, por lo tanto, múltiples DLL para cada uno de estos objetivos o existe alguna forma de generar una DLL común para que todos la utilicen?

Answer 1

El camino a seguir es separar los archivos del proyecto con archivos fuente compartidos y comunes. Asegúrese de que los proyectos estén configurados para compilarse en diferentes carpetas de salida (por ejemplo, no /bin/Debug , pero /CF/bin/debug ) para evitar molestias al consumir la biblioteca desde varios destinos (como un proyecto de escritorio y dispositivo).

El marco OpenNETCF.IoC es un ejemplo de esto: admite el escritorio, CF, Windows Phone y MonoTouch, todos con los mismos archivos fuente, pero archivos de proyecto separados por plataforma. Tratar de compilar un único ensamblaje binario que se pueda usar en todos ellos era demasiado complicado y difícil de mantener.

El punto principal aquí es mantener todos los archivos del proyecto sincronizados cuando agrega / cambia archivos y se asegura de que todos compilen siempre. Un servidor de compilación puede hacer eso si tiene acceso a la automatización (que Codeplex desafortunadamente no expone).

Answer 2

Hago algo similar con una biblioteca que apunta a .NET y Silverlight. Tengo un único conjunto de archivos de origen y archivos de proyecto separados que se vinculan a los mismos archivos compartidos.

A veces utilizo la compilación condicional para incluir funciones solo para .NET y no para Silverlight, o para aprovechar las funciones disponibles en .NET que conducen a una implementación más agradable y una implementación posterior para Silverlight donde tiene lagunas.

El mismo enfoque podría usarse para las otras plataformas que mencione: un conjunto de archivos fuente, pero un archivo de proyecto separado por destino de plataforma.

Si utiliza una herramienta de compilación como MSBuild o NAnt, puede hacer que la compilación produzca todos los archivos DLL para todas las plataformas de destino cuando ejecuta el script.

Answer 3

Hubo una charla en PDC este año sobre hacer este tipo de cosas:

Este es el video y estas son las diapositivas .

Answer 4

Mire la extensión Portable Library Tools (Last Updated: 6/17/2011) de BLC Team (Microsoft) y esta introducción al artículo de MSDN (Última actualización: agosto de 2011).

Answer 5

Sugeriría una biblioteca para cada plataforma. Dejame explicar.

Digamos que el .NET Framework completo incluye un conjunto de características, métodos que no son parte de .NET Compact Framework como el que puede encontrar con Windows CE y teléfonos inteligentes. Entonces, para poder aprovechar al máximo todas las posibilidades de cada plataforma, aprovecharé una biblioteca común con muchas interfaces, luego implementará esas interfaces dentro de una biblioteca de clases .NET Framework platform specific que le permitirá aprovechar al máximo sobre lo que se ofrece en una plataforma específica.

Por otro lado, si se reutiliza el código de forma común y, por el bien de la mantenibilidad, es posible que prefiera ir con una sola biblioteca "do-them-all". De acuerdo con dichos requisitos, deberá estar completamente al tanto de cada una de las diferencias entre las muchas plataformas que desea admitir.

Esta es obviamente una pregunta importante de análisis y arquitectura, ya que ambos sufrirán las carencias de una plataforma sobre la otra.

Así es como procedería ante tal situación:

1. Investigaría las diferencias entre el Framework .NET específico de la plataforma;
2. Dejaría de lado todo (según sea necesario) los objetos comunes que crees que podrías necesitar;
3. Destacaría las diferencias, es decir, los objetos que puede usar en una plataforma, pero no en la otra;

Este es un análisis orgánico que tendrá que realizar para ver qué viene a continuación.

Es decir, para un tipo de enfoque de cascada.

En cuanto a un enfoque de Scrum, si puedo decirlo, ya que esto sugiere empirismo, diría que prueben una sola biblioteca común para todos ellos, y vean lo que pueden hacer. Si te encuentras con algunas cosas que no puedes hacer, puede ser relevante crear otra biblioteca de clases que dependa de tu biblioteca "do-them-all" para que tengas un bloque común para cada plataforma, y ​​luego otra específica bibliotecas por lo que no puedes hacer en común. Hazlo, y mira qué ventajas obtienes de él, y encuentra una forma de salir de problemas cuando llegue el momento de ser más específico.