¿Debe un .sln estar comprometido con el control de fuente?


101

¿Es una buena práctica enviar un archivo .sln al control de código fuente? ¿Cuándo es apropiado o inapropiado hacerlo?

Actualización Hubo varios puntos buenos en las respuestas. ¡Gracias por las respuestas!


21
Creo que es el archivo .SUO que NO desea comprometer.
apandit

Solo para que conste, creo que las listas de tareas (si las usa) se almacenan en el archivo .SUO ... Entonces, aunque es posible que no desee enviarlas al control de código fuente, es posible que no desee 'simplemente eliminarlas' como cruft extraño.
Benjol

Respuestas:


69

Creo que está claro por las otras respuestas que los archivos de solución son útiles y deben confirmarse, incluso si no se usan para compilaciones oficiales. Son útiles para cualquiera que use funciones de Visual Studio como Ir a definición / declaración.

De forma predeterminada, no contienen rutas absolutas ni ningún otro artefacto específico de la máquina. (Desafortunadamente, algunas herramientas complementarias no mantienen adecuadamente esta propiedad, por ejemplo, AMD CodeAnalyst). Si tiene cuidado de usar rutas relativas en los archivos de su proyecto (tanto C ++ como C #), serán independientes de la máquina también.

Probablemente la pregunta más útil es: ¿qué archivos debería excluir? Aquí está el contenido de mi archivo .gitignore para mis proyectos VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(La última entrada es solo para el generador de perfiles AMD CodeAnalyst).

Para VS 2010, también debe excluir lo siguiente:

ipch/
*.sdf
*.opensdf

2
También tengo una regla de ignorar para los resultados de las pruebas unitarias. Algunas personas pueden registrarlos, pero no me gusta el desorden
Matthew Whited

9
+1 - Personalmente tampoco cometo nada que se construya, por lo tanto bin / y obj /
Steven Evers

Solo confirmo archivos .sln que contienen más de 1 proyecto
Justin

2
aquí está mi patrón de ignorar global de subversion: * .vsmdi * .suo * / [Bb] en [Bb] en * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish. xml * Web.log
Merritt

Aquí hay un archivo .gitignore comúnmente compartido que incluye archivos temporales, resultados de compilación y archivos generados por complementos populares de Visual Studio.
Lauren Van Sloun

58

Sí, creo que siempre es apropiado. La configuración específica del usuario se encuentra en otros archivos.


3
Definitivamente el .sln tiene referencias a los archivos .prj (proyectos)
dplante

20

Sí, deberías hacer esto. Un archivo de solución contiene solo información sobre la estructura general de su solución. La información es global para la solución y probablemente sea común para todos los desarrolladores de su proyecto.

No contiene ninguna configuración específica del usuario.


13

Definitivamente deberías tenerlo. Además de las razones que mencionaron otras personas, es necesario hacer posible la construcción en un solo paso de todos los proyectos.


8

En general, estoy de acuerdo en que los archivos de solución deben registrarse, sin embargo, en la empresa para la que trabajo hemos hecho algo diferente. Tenemos un repositorio bastante grande y los desarrolladores trabajan en diferentes partes del sistema de vez en cuando. Para respaldar la forma en que trabajamos, tendríamos un archivo de solución grande o varios más pequeños. Ambos tienen algunas deficiencias y requieren un trabajo manual por parte de los desarrolladores. Para evitar esto, hemos creado un complemento que maneja todo eso.

El complemento permite a cada desarrollador consultar un subconjunto del árbol de origen para trabajar simplemente seleccionando los proyectos relevantes del repositorio. Luego, el complemento genera un archivo de solución y modifica los archivos del proyecto sobre la marcha para la solución dada. También maneja referencias. En otras palabras, todo lo que el desarrollador tiene que hacer es seleccionar los proyectos apropiados y luego se generan / modifican los archivos necesarios. Esto también nos permite personalizar otras configuraciones para garantizar los estándares de la empresa.

Además, usamos el complemento para admitir varias políticas de registro, lo que generalmente evita que los usuarios envíen código defectuoso / no compatible al repositorio.


Parece que esta podría ser la respuesta a una de mis preguntas sin respuesta ( stackoverflow.com/questions/1490728/… ), ¿hay alguna posibilidad de obtener una copia de este complemento?
Benjol

@Benjol: Lo siento, no, es una herramienta interna. Además de las características anteriores, también se integra con varios otros sistemas internos, por lo que es muy específico de cómo ejecutamos las cosas. Si solo necesita la parte de la solución / proyecto, no es tan difícil de implementar.
Brian Rasmussen

Bien, solo una cosa, en su 'gran solución' ¿tiene referencias de proyectos o referencias de archivos? Y si un desarrollador agrega una nueva referencia a un archivo / proyecto, ¿el complemento realiza la conversión adecuada antes de registrarse? ¿Y cómo maneja las dependencias que el desarrollador no ha decidido verificar?
Benjol

8

Sí, las cosas que debes cometer son:

  • solución (* .sln),
  • archivos de proyecto,
  • todos los archivos de origen,
  • archivos de configuración de la aplicación
  • construir scripts

Las cosas que no debes cometer son:

  • archivos de opciones de usuario de la solución (.suo),
  • compilar archivos generados (por ejemplo, usando un script de compilación) [Editar:] - solo si todos los scripts y herramientas de compilación necesarios están disponibles bajo el control de versiones (para garantizar que las compilaciones sean auténticas en el historial de CVS)

Con respecto a otros archivos generados automáticamente, hay un hilo separado .


1
Tengo que estar en desacuerdo con "cualquier archivo generado automáticamente".
Mehrdad Afshari

@Mehrdad, ¿crees que los archivos Intelisense también deberían confirmarse?
Edison Gustavo Muenz

1
@Edison: Nop. Me refiero a archivos fuente generados automáticamente como LINQ to SQL data context, por ejemplo.
Mehrdad Afshari

2
¿No se consideran los archivos Formname.Designer.cs generados automáticamente?
jasonh

1
Lo que quise decir fueron archivos generados durante el tiempo de compilación. Encuentro esto a menudo: alguien confirma un archivo que se crea automáticamente y luego SVN informa un cambio solo porque se modificó algún comentario.
Groo

5

Sí, debería ser parte del control de fuente. Siempre que agregue / elimine proyectos de su aplicación, .sln se actualizará y sería bueno tenerlo bajo control de código fuente. Le permitiría extraer las versiones del código 2 de su aplicación y hacer una compilación directamente (si es necesario).


5

En la mayoría de circunstancias, es una buena idea enviar archivos .sln al control de código fuente.

Si sus archivos .sln son generados por otra herramienta (como CMake), probablemente sea inapropiado ponerlos en control de código fuente.


4

Sí, siempre quieres incluir el archivo .sln, incluye los enlaces a todos los proyectos que están en la solución.


2

Lo hacemos porque mantiene todo sincronizado. Todos los proyectos necesarios se encuentran juntos y nadie tiene que preocuparse por perder uno. Nuestro servidor de compilación (Ant Hill Pro) también usa sln para determinar qué proyectos construir para una versión.


2

Por lo general, colocamos todos nuestros archivos de soluciones en un directorio de soluciones. De esta manera separamos un poco la solución del código, y es más fácil elegir el proyecto en el que necesito trabajar.


1

El único caso en el que incluso consideraría no almacenarlo en el control de fuente sería si tuviera una solución grande con muchos proyectos que estuviera en control de fuente y quisiera crear una solución pequeña con algunos de los proyectos de la solución principal para algunos requisito transitorio privado.


1

Sí, todo lo que se utiliza para generar su producto debe estar bajo control de fuente.


1

Guardamos archivos de solución en TFS Version Control. Pero dado que nuestra solución principal es realmente grande, la mayoría de los desarrolladores tienen una solución personal que contiene solo lo que necesitan. El archivo de solución principal lo utiliza principalmente el servidor de compilación.


0

.slns es lo único con lo que no hemos tenido problemas en tfs.


1
Es gracioso ... Los SLN fueron los únicos archivos que tuve que arreglar ... pero los problemas fueron causados ​​por los desarrolladores que no tenían cuidado con las fusiones.
Matthew Whited
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.