2009-06-15 7 views
28

Estábamos pensando en organizar nuestro proyecto BIG esta manera:convención de nomenclatura para las soluciones de Visual Studio y proyecta

 
\trunk 
    [CompanyName] 
    [Product1] 
     [Project1] 
      CompanyName.Product1.Project1.csproj 
     [Project2] 
      CompanyName.Product1.Project2.csproj 
     CompanyName.Product1.sln 
    [Product2] 

Estábamos tratando de seguir la recomendación de Microsoft de que los nombres de espacio de nombres siguen la estructura de carpetas, pero ¿hay inconvenientes para hacer de esta manera? ¿Cuál es la convención de nomenclatura para soluciones y proyectos que aplica?

Respuesta

9

Eso se ve muy bien si me preguntas. Nombrar especialmente sus proyectos por su nombre completo, incluida la parte del espacio de nombre completo. Lo encontré útil cuando hay numerosos proyectos, especialmente si hay proyectos similares en diferentes productos.

Cómo y si se divide en producto y proyecto (donde supongo que el proyecto se parece más a una aplicación que a un proyecto de solución) es muy inferior al tamaño de su organización, su composición y sus preferencias.

1

Parece sacado del libro de la escuela. Por lo general, así se configuran mis soluciones, y he descubierto que funciona bastante bien a lo largo de los años.

0

Se ve bien conmigo.

Es un punto a tener en cuenta que, de forma predeterminada, el espacio de nombres predeterminado en un proyecto de Visual Studio es solo el nombre del proyecto. Seguramente eso indica que nombrar sus proyectos como sus espacios de nombres es "el Visual Studio Way".

Las soluciones se nombran más naturalmente después del producto/proyecto. Como usted indica

1

Con respecto a los nombres de archivo, prefiero que el nombre del archivo de proyecto coincida con el nombre del ensamblado de salida porque hace que sea mucho más fácil saber qué produce qué. Hacer una lista de directorios es mucho más rápido que buscar los archivos csproj en un árbol para el que produce el ensamblaje que me importa.

No me preocupo por los archivos de soluciones porque no influyen en nuestro entorno de compilación, así que termino haciendo los míos para tener el alcance exacto que quiero (y los elementos específicos por solución, como metadatos de prueba, lo que quiero).

Con respecto a la estructura de carpetas, no me preocupo demasiado si las carpetas que llevan los archivos de proyecto coinciden con los espacios de nombres. Quiero que mi código se coloque en el disco de una manera que tenga más sentido para el proyecto. A veces esto significa que el código de prueba y el código del producto están en los directorios de hermanos, a veces significa que están mucho más separados. A veces hay un espacio de nombres al que contribuyen varios equipos (no defienden ese diseño, solo una realidad), pero esos equipos quieren vivir en sus propias carpetas por cualquier razón.

No olvide la importancia de las estrategias de ramificación de control de versiones en el diseño general de su proyecto. Los límites de la Compañía y del Producto pueden ser sucursales y, por lo tanto, no necesariamente deben representarse como directorios en el disco.

No deje que esto sea una fuente de parálisis de análisis. Haz una elección razonable. Usa control de versiones Siempre puede cambiar más tarde si está equivocado.

3

Una alternativa que he usado es tener todos mis archivos de solución en el mismo directorio.

\trunk 
    [CompanyName] 
    CompanyName.Product1.sln 
    CompanyName.Product2.sln 
    [Product1] 
     [Project1] 
      CompanyName.Product1.Project1.csproj 
     [Project2] 
      CompanyName.Product1.Project2.csproj 
    [Product2] 
     [Project3] 
      CompanyName.Product2.Project3.csproj 
Cuestiones relacionadas