proyecto existe destino argumentos c# visual-studio msbuild

existe - Estructura del Proyecto para el Esfuerzo de Desarrollo de C#



msbuild reduce verbosity (4)

¿Qué estructura de directorio / solución / proyecto considera que es la más manejable y conveniente para proyectos medianos y grandes escritos en C #? Por "mediano a grande" me refiero a proyectos que incluyen un conjunto diverso de tipos de proyectos de Visual Studio C # en una estructura jerárquica con espacios de nombres anidados. 1

Principalmente estoy interesado en los tipos de proyectos que se encuentran en la sección ''Windows'' en Visual Studio 2008: Windows Forms, WPF, controles personalizados para ambos y bibliotecas de clases. Además, estoy usando MSBuild (a través de Visual Studio) para construir mi proyecto.

Nunca encontré la estructura predeterminada generada automáticamente por Visual Studio para que valga la pena usarla. Esta estructura tiene una carpeta únicamente para contener la solución y una carpeta anidada para cada proyecto. Me pregunto si esto se debe a la escala del proyecto en el que he usado C # en el pasado (pequeño a mediano). ¿Qué beneficios tiene esta estructura para proyectos más grandes? ¿Lo has encontrado útil?

También me interesan cosas como los nombres de las carpetas y su relación con los espacios de nombres.

Los siguientes son mis objetivos personales para la estructura del proyecto.

Metas

  • Cada proyecto debe ser razonablemente autónomo. Es decir, preferiría poder verificar cada uno individualmente y compilarlo (donde lo permitan las dependencias).
  • Navegar por la estructura debería ser fácil.
  • Las estructuras de directorios deben correlacionarse con los espacios de nombres de una manera clara y directa.
  • Identificar archivos de solución debería ser fácil.

  • Los proyectos deberían compilarse con poco o ningún esfuerzo adicional en Visual Studio (MSBuild) en la mayoría o en todos los niveles de la jerarquía.

    1. Tenga en cuenta que mi uso de la palabra "proyectos" aquí significa "esfuerzos de desarrollo", excepto donde se indique explícitamente.

Actualmente utilizo una estructura donde todo el sistema se divide en partes lógicas, cada parte es una solución de Visual Studio por separado. Cada solución está contenida en una estructura de carpetas con el siguiente aspecto:

[logical part name] |-doc |-lib |- // any non-GAC-assemblies needed by the projects in the solution |-src |-Production | |-Project1 | |-Project2 |-Tests |-UnittestProject1 |-UnittestProject2 |-tools |- // any tools needed for automated builds and such // (NUnit, NCover, MSBuild tasks, ...)

Esto requiere un desplazamiento de los archivos (por ejemplo, el resultado de una parte lógica a la que hace referencia otro debe moverse a la carpeta de lib de esa otra parte), pero esto se puede automatizar fácilmente dentro de un script de MSBuild. También tenemos una secuencia de comandos de MSBuild que llama a los scripts de MSBuild de cada una de las partes lógicas en orden, y mueve la salida a las carpetas de lib apropiadas. De esta forma puedo construir la parte lógica con la que estoy trabajando actualmente en un solo paso, y también hacer una compilación del sistema completo con un solo clic (o, bueno, hacer doble clic).

Hemos utilizado esa estructura en el proyecto actual durante el último año y medio, y parece funcionar bastante bien.

Para los proyectos de C #, utilizo generalmente una estructura de capa N. Algo como:

/ projectname_interface_layer / / projectname_service_layer / / projectname_business_layer / / projectname_data_layer /

Esto tiene la ventaja de ofrecer una clara separación lógica entre las diferentes entidades de la aplicación.

Qué hacemos:

Tenemos soluciones separadas, repositorios de subversión y compilaciones para cada capa.

Cada capa tiene compilaciones de dependencia, por lo que crear una capa inferior hará que esa capa se construya.

Cada capa tiene un directorio Lib con externos apuntando a los directorios de salida de la capa inferior.

Antes de una compilación, cualquier capa (que no sea la raíz) hará una actualización en la (s) carpeta (s) externa (s), insertando los últimos binarios. Si la construcción es exitosa, actualizará el enlace externo a la última versión, y luego verifica sus propios binarios. Esto activará la siguiente construcción en la cadena, etc.

De esta forma, un cambio de ruptura en una capa de nivel inferior generará una falla en la cadena, pero si realiza una obtención desde la capa de nivel superior, seguirá funcionando en la facturación funcional más reciente.

En cuanto a la decisión sobre capas, prácticamente tenemos una capa de marco, capas de lógica de negocios y capas de presentación (ya sea servicio web, aplicación o sitio web).

En cuanto a las pruebas, deberían estar en la misma solución que lo que están probando, pero diferentes ensamblajes. Los ensambles de prueba nunca se deben implementar en un entorno de producción. La razón es que a menudo, si no siempre, sus ensamblajes de prueba serán ensamblajes "amigos" de los reales. Asumiendo que un atacante puede ejecutar cualquier miembro público en asambleas desplegadas, esto les da acceso no solo a los miembros públicos en su código real, sino también a los internos.

Además, mantenemos cosas relacionadas con la construcción, herramientas, archivos de configuración, etc., en su propio repositorio, separado del código.