Mejores prácticas para una biblioteca .NET de múltiples objetivos

Question

Estoy planeando lanzar una biblioteca .NET de código abierto (MIT), pero también incluir archivos DLL para que sea más fácil para las personas, de modo 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 (Phone), 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, p. HashSet<T> no está disponible en Windows Phone 7, así que no lo estoy usando.

¿Tendré que crear diferentes proyectos y, por lo tanto, varias DLL para cada uno de estos objetivos o hay alguna forma de producir una DLL común para que la utilicen todos?

Answer 1

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

Este es el vídeo y estos son los toboganes .

Answer 2

Los archivos de proyectos compartidos por separado con ficheros de fuentes comunes es el camino a seguir. Asegúrese de que los proyectos se establecen en la acumulación de diferentes carpetas de salida (por ejemplo, no \bin\Debug, pero \CF\bin\debug) para evitar molestias cuando consumen la biblioteca de múltiples objetivos (como un proyecto de escritorio y el dispositivo).

El OpenNETCF.IoC marco es un ejemplo de esto - es compatible con el escritorio, CF, Windows Phone y MonoTouch todos con los mismos archivos de origen, pero los archivos de proyecto separados por plataforma. Intentar compilar a un único conjunto binario que se puede utilizar en todos ellos era demasiado complicado y difícil de mantener.

El punto principal aquí el dolor es mantener todos los archivos de proyecto en sincronía cuando se agrega / archivos de cambios y asegurarse de que todos ellos siempre se compila. Un servidor de compilación puede hacerlo si tiene acceso a la automatización (que CodePlex lamentablemente no expone).

Answer 3

He hecho algo similar con una biblioteca que los objetivos .NET y Silverlight. Tengo un único conjunto de archivos de código fuente y archivos de proyectos independientes que enlazan con los mismos archivos compartidos.

A veces uso la compilación condicional para incluir características sólo para .NET y Silverlight no, o para tomar ventaja de las características disponibles en .NET que conducen a una implementación más agradable y una aplicación posterior caída para Silverlight donde tiene lagunas.

El mismo enfoque podría ser utilizado para las otras plataformas que mencionas -. Un conjunto de archivos de origen, sino un archivo de proyecto independiente para cada plataforma de destino

Si utiliza una herramienta de construcción como MSBuild o de NAnt, a continuación, puede tener la acumulación de producto todas las DLL para todas las plataformas de destino cuando se ejecuta la secuencia de comandos.

Answer 4

Mire la portátil Herramientas de bibliotecas (Última actualización: 6/17/2011) extensión de BLC equipo (Microsoft) y esta introducción MSDN artículo (Última actualización: agosto de 2011).

Answer 5

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

digamos el completo .NET Framework incluye un montón de características, métodos que no son parte del .NET Compact Framework como el que puedes encontrar con Windows CE y teléfonos inteligentes.Entonces, para aprovechar al máximo la carga completa de posibilidades de cada plataforma, aprovecharía una biblioteca común con muchas interfaces y luego implementarías esas interfaces dentro de un .NET Framework platform specific Biblioteca de clases que te permitirá aprovechar al máximo lo que se ofrece en una plataforma específica.

Por otro lado, si se trata de una reutilización común del código, y por razones de mantenimiento, es posible que prefiera optar por una única biblioteca que pueda "hacerlo todo".Según tales requisitos, deberá ser plenamente consciente de cada una de las diferencias entre las muchas plataformas que desea admitir.

Esta es obviamente una cuestión importante de análisis y arquitectura, ya que ambas 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 .NET Framework específico de la plataforma;
2. Yo dejaría de lado todos (según sea necesario) los objetos comunes que crea que podría necesitar;
3. Destacaría las diferencias, es decir, objetos que puedes usar bajo una plataforma, pero no en la otra;

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

Es decir, para una especie de enfoque en cascada.

---

En cuanto al enfoque Scrum, si se me permite decirlo, ya que esto sugiere empirismo, diría que pruebe una única biblioteca común para todos y vea qué puede hacer.Si encuentra algunas cosas que no puede hacer en absoluto, entonces podría ser relevante crear solo otra biblioteca de clases que dependa de su biblioteca de "hacerlas todas" para que tenga un bloque común para cada plataforma, luego algunas otras específicas. bibliotecas para lo que no puedes hacer en lo común.Hágalo y vea qué ventajas obtuvo de ello y encuentre una manera de salir del problema cuando llegue el momento de ser más específico.