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

¿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!

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

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

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.

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.

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.

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 .

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).

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.

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

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.

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.

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.

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

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.

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