Práctica recomendada para una biblioteca .NET de varios destinatarios

Question

Estoy planeando lanzar una biblioteca .NET de código abierto (MIT), pero también 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 varios 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 de tipos que no estén disponibles en las plataformas a las que me dirijo, p. HashSet<T> no está disponible en Windows Phone 7, así que no lo estoy usando.

¿Tendré que hacer diferentes proyectos y, por lo tanto, varias DLL para cada uno de estos objetivos o existe alguna forma de producir una DLL común para que todos puedan usar?

Answer 1

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

This is the video y these are the slides.

Answer 2

Sugeriría una biblioteca para cada una de las plataformas. Dejame explicar.

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

Por otro lado, si es una reutilización común del código, y por razones de mantenimiento, es posible que prefiera ir con una única 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.

Esto 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 me gustaría proceder frente a una situación de este tipo:

1. que investigaría las diferencias entre la plataforma específica de .NET Framework;
2. Dejaría de lado todo (según sea necesario) los objetos comunes que crees que podrías necesitar;
3. Destacaré 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 una especie de enfoque de cascada.

---

En cuanto a un enfoque Scrum, si se puede decir así, ya que sugiere el empirismo, yo diría que probar una sola biblioteca común para todos ellos, y ver lo que puede hacer. Si te encuentras con algunas cosas que no puedes hacer, entonces 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.

Answer 3

Hago algo similar con una biblioteca que se dirige 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.

Algunas 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 fallida 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 4

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

El OpenNETCF.IoC framework 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 de 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 5

Mira el Portable Library Tools (Última actualización: 6/17/2011) extensión desde BLC equipo (Microsoft) y esta introducción MSDN article (Última actualización: agosto de 2011).