¿Cuál es la forma estándar de la industria para organizar los proyectos de Visual Studio y el código para el desarrollo multiplataforma de.NET

visual-studio mono

Question

Tengo una solución bastante grande de proyectos de C # en Visual Studio. Quiero portar algunos de esos proyectos para trabajar en MONO y ejecutar decir en un MAC. Por supuesto, algunas cosas no funcionan y algunas cosas que no quiero portar porque no son aplicables en un MAC.

Un enfoque es la solución y las configuraciones del proyecto. Esto me permite excluir proyectos que no quiero compilar (lamentablemente, Visual Studio no los hace fácilmente visibles, pero de todos modos ...).

El segundo enfoque que podría funcionar en conjunto con el primero es usar directivas de compilador previo como #if MONO y luego hacer algo en ese punto. Esto es bueno, pero luego crea múltiples versiones del mismo ensamblaje. ¿Cómo distingo los dos de cada una de las compilaciones de publicaciones? ¿Es esto un problema?

Incluso si los dos primeros enfoques funcionan, a veces quiero formar parte de un gran proyecto. No quiero pasar por 20 o más archivos y poner # si MONO ¿verdad? Puedo copiar el archivo del proyecto a mano, pero no hay visibilidad en eso en Visual Studio. Nadie más en el equipo puede decir lo que está pasando a menos que descarguen el proyecto y abran el XML y lo echen un vistazo. Esto suena bastante loco. Para empeorar las cosas, a veces el proyecto hace referencia a algo y quiero excluir la referencia para MONO. Ahora tengo que editar el csproj.

Puedo dividir el proyecto, pero ¿qué ocurre si en algún momento deseo realizar el acceso a otra plataforma? Las intersecciones de qué plataforma necesita qué código puede volverse loco. Para empeorar las cosas, puedo tener proyectos que hagan referencia a este gran proyecto, que también puede tener que dividirse. Todo esto funciona, pero causará una sobrecarga del proyecto, ¿no?

No puedo encontrar una buena solución limpia. ¿Algun consejo? ¿Existe un estándar para esto que pueda seguir? Si VS tuviera más visibilidad en las ediciones del archivo csproj, podría funcionar.

Answer 1

Como regla general, mantenga los proyectos en una solución pequeña y concisa; Los bits dependientes de la plataforma idealmente deberían implementarse en proyectos separados. Es posible que desee ver los métodos de diseño de creaciones de software, como el patrón abstracto de fábrica, para mantener las dependencias específicas de la plataforma bajas, agrupadas y controladas.

En un nivel abstracto, un enfoque para monitorear el desarrollo es usar Team Foundation Server (TFS). Básicamente proporciona la funcionalidad de git para el desarrollo de Visual Studio, por lo que puede seguir fácilmente csproj. Si tiene un equipo que trabaja en Java o Android, etc. a través de Eclipse, puede usar TFS a través del complemento TFS para mantener a todos en la misma página y hacer un seguimiento de los cambios y las revisiones en los proyectos y en su solución general.

Normalmente, los proyectos con implementaciones potencialmente multiplataforma se estructuran desde cero de esta manera, directamente desde la etapa de visualización y planificación. Si está atascado con un proyecto que ahora desea exportar, podría usar las dos primeras opciones que sugirió, y si diferenciar los ensamblados es un problema, existen varios descompiladores de terceros que pueden hacer el trabajo por usted.

Espero que ayude.

Answer 2

Este es un problema de programación bien conocido, si existe una solución, generalmente requieren un poco de trabajo y más cuando un proyecto no está diseñado desde cero para ser portátil. Como correctamente señaló, el enunciado preprocesado se convertirá rápidamente en una carga general y en un verdadero dolor para mantener y expandir con el tiempo.

Sin embargo, no es fácil responder a esta pregunta directamente, ya que la solución que está buscando puede ser altamente dependiente de su implementación. En términos generales, le aconsejo que haga un uso extenso del patrón de diseño conocido, como Abstract Factory , Bridge , Facade , etc.

Como ejemplo, comience por identificar cada pieza de código que dependa de la plataforma, defina las interfaces de API responsables de manejar estas especificidades en su proyecto principal e impleméntelas en proyectos dedicados, generalmente uno por plataforma. Una vez hecho esto, regrese a su proyecto principal y defina una interfaz que contendrá métodos de fábrica para instanciar estas clases específicas. Nuevamente implementa fábricas específicas en sus respectivos proyectos.

En este punto, puede decidir en tiempo de ejecución qué servidor desea usar seleccionando la fábrica que instanciará sus clases. El siguiente paso sería proporcionar algún sistema enchufable para cargar la fábrica deseada en tiempo de ejecución, gracias a la reflexión esta parte es probablemente la más fácil. Revise todos los ensamblados contenidos en una carpeta especial, analice sus tipos para detectar si implementan las interfaces de fábrica y, si lo hacen, cárguelos.

Answer 3

También podría configurar una estructura de carpetas y dividir su solución en una solución común que contenga proyectos independientes de la plataforma y soluciones específicas de la plataforma que contengan proyectos específicos de la plataforma.

Entonces, por ejemplo, un application.sln que contenga todos sus proyectos comunes y, en aras de la discusión, también tenemos una solución iOS y Android.

• carpeta raíz
  • aplicación (carpeta)
  • aplicación.Droid (carpeta)
  • aplicación.Ios (carpeta)
  • application.sln
  • application.Droid.sln
  • application.Ios.sln

Dentro de las soluciones específicas de la plataforma, puede hacer referencia a los proyectos comunes agregando, por ejemplo, una carpeta ''[aplicación]'' con subcarpetas de proyectos comunes adicionales a sus proyectos específicos de la plataforma. Suma sucesivamente todos los archivos comunes necesarios como enlaces.

La respuesta anterior es una de las posibilidades que también podrías:

• Cree una biblioteca de clases portátil que comparta entre proyectos específicos de la plataforma
• Use MvvmCross ( MvvmCross GitHub ) para que tenga un proyecto central al que pueda hacer referencia en sus proyectos específicos de plataforma