¿Debo agregar los archivos .suo y .user de Visual Studio al control de origen?

Las soluciones de Visual Studio contienen dos tipos de archivos de usuario ocultos. Uno es el .suoarchivo de solución que es un archivo binario. El otro es el .userarchivo del proyecto , que es un archivo de texto. ¿Qué datos contienen exactamente estos archivos?

También me he estado preguntando si debería agregar estos archivos al control de origen (Subversion en mi caso). Si no agrego estos archivos y otro desarrollador comprueba la solución, ¿Visual Studio creará automáticamente nuevos archivos de usuario?

Estos archivos contienen configuraciones de preferencia del usuario que en general son específicas de su máquina, por lo que es mejor no ponerlo en SCM. Además, VS lo cambiará casi cada vez que lo ejecute, por lo que SCM siempre lo marcará como 'modificado'. No incluyo tampoco, estoy en un proyecto usando VS durante 2 años y no tuve problemas para hacerlo. La única molestia menor es que los parámetros de depuración (ruta de ejecución, destino de implementación, etc.) se almacenan en uno de esos archivos (no sé cuál), por lo que si tiene un estándar para ellos, no podrá ' publíquelo a través de SCM para que otros desarrolladores tengan todo el entorno de desarrollo "listo para usar".

No es necesario agregarlos: contienen configuraciones por usuario y otros desarrolladores no querrán su copia.

Otros han explicado por qué no es una buena idea tener los archivos *.suoy *.userbajo control de origen.

Me gustaría sugerir que agregue estos patrones a la svn:ignorepropiedad por 2 razones:

1. Por lo tanto, otros desarrolladores no terminarán con la configuración de un desarrollador.
2. Por lo tanto, cuando vea el estado o confirme archivos, esos archivos no saturarán la base del código y oscurecerán los nuevos archivos que necesita agregar.

No confirmamos el archivo binario (* .suo), pero confirmamos el archivo .user. El archivo .user contiene, por ejemplo, las opciones de inicio para depurar el proyecto. Puede encontrar las opciones de inicio en las propiedades del proyecto en la pestaña "Depurar". Usamos NUnit en algunos proyectos y configuramos nunit-gui.exe como la opción de inicio del proyecto. Sin el archivo .user, cada miembro del equipo tendría que configurarlo por separado.

Espero que esto ayude.

Desde que encontré esta pregunta / respuesta a través de Google en 2011, pensé en tomar un segundo y agregar el enlace para los archivos * .SDF creados por Visual Studio 2010 a la lista de archivos que probablemente no deberían agregarse al control de versiones ( el IDE los volverá a crear). Como no estaba seguro de que un archivo * .sdf pudiera tener un uso legítimo en otro lugar, solo ignoré el archivo [projectname] .sdf específico de SVN.

¿Por qué el asistente de conversión de Visual Studio 2010 crea un archivo masivo de base de datos SDF?

No, no debe agregarlos al control de fuente ya que, como usted dijo, son específicos del usuario.

SUO (Opciones de usuario de la solución): registra todas las opciones que puede asociar con su solución para que cada vez que la abra, incluya las personalizaciones que haya realizado.

El archivo .user contiene las opciones de usuario para el proyecto (mientras que SUO es para la solución) y extiende el nombre del archivo del proyecto (por ejemplo, anything.csproj.user contiene configuraciones de usuario para el proyecto anything.csproj).

Esta parece ser la opinión de Microsoft al respecto:

Agregar (y editar) archivos .suo al control de origen

No sé por qué su proyecto almacena el DebuggingWorkingDirectory en el archivo suo. Si esa es una configuración específica del usuario, debería considerar almacenarla en el nombre de archivo * .proj.user. Si esa configuración se puede compartir entre todos los usuarios que trabajan en el proyecto, debería considerar almacenarla en el archivo del proyecto.

¡Ni se te ocurra agregar el archivo suo al control de origen! El archivo SUO (opciones de usuario de solución) está destinado a contener configuraciones específicas del usuario y no debe compartirse entre los usuarios que trabajan en la misma solución. Si agregaría el archivo suo en la base de datos scc, no sé qué otras cosas en el IDE rompería, pero desde el punto de vista del control de origen romperá la integración scc de proyectos web, se utilizó el complemento Lan vs Internet por diferentes usuarios para el acceso VSS, e incluso podría causar que el scc se rompa por completo (la ruta de la base de datos VSS almacenada en el archivo suo que puede ser válida para usted puede no ser válida para otro usuario).

Alin Constantin (MSFT)

De forma predeterminada, Visual SourceSafe de Microsoft no incluye estos archivos en el control de origen porque son archivos de configuración específicos del usuario. Seguiría ese modelo si estás usando SVN como control de fuente.

Visual Studio los creará automáticamente. No recomiendo ponerlos en control de fuente. Ha habido numerosas ocasiones en que el archivo SOU de un desarrollador local estaba causando que VS se comportara de manera errática en esa caja de desarrolladores. Eliminar el archivo y luego dejar que VS lo vuelva a crear siempre solucionó los problemas.

En el sitio web de MSDN , establece claramente que

El archivo de opciones de usuario de solución (.suo) contiene opciones de solución por usuario. Este archivo no debe registrarse en el control del código fuente .

Por lo tanto, diría que es bastante seguro ignorar estos archivos al registrar cosas en su control de origen.

Yo no lo haría Cualquier cosa que pueda cambiar por "usuario" generalmente no es buena en el control de la fuente. Directorios .suo, .user, obj / bin

Estos archivos son opciones específicas del usuario, que deberían ser independientes de la solución misma. Visual Studio creará nuevos según sea necesario, por lo que no es necesario que se registren para controlar la fuente. De hecho, probablemente sería mejor no hacerlo, ya que esto permite a los desarrolladores individuales personalizar su entorno como mejor les parezca.

No puede controlar el origen de los archivos .user, porque eso es específico del usuario. Contiene el nombre de la máquina remota y otras cosas dependientes del usuario. Es un archivo relacionado con vcproj.

El archivo .suo es un archivo relacionado con sln y contiene las "opciones de usuario de la solución" (proyecto (s) de inicio, posición de Windows (qué está acoplado y dónde, qué está flotando), etc.)

Es un archivo binario, y no sé si contiene algo "relacionado con el usuario".

En nuestra empresa no tomamos esos archivos bajo control de origen.

Contienen la configuración específica sobre el proyecto que generalmente se asigna a un único desarrollador (como, por ejemplo, el proyecto de inicio y la página de inicio para comenzar cuando depura su aplicación).

Por lo tanto, es mejor no agregarlos al control de versiones, dejando que VS los vuelva a crear para que cada desarrollador pueda tener la configuración específica que desee.

.user es la configuración del usuario, y creo que .suo es la opción de usuario de la solución. No desea que estos archivos estén bajo control de origen; serán recreados para cada usuario.

No.

Solo quería una respuesta realmente corta, y no había ninguna.

Usando Rational ClearCase la respuesta es no. Solo el .sln &. * Proj debe registrarse en el control del código fuente.

No puedo responder por otros vendedores. Si recuerdo correctamente, estos archivos son opciones específicas de "usuario", su entorno.

No agregue ninguno de esos archivos al control de versiones. Estos archivos se generan automáticamente con información específica de la estación de trabajo, si se registra en el control de versión que causará problemas en otras estaciones de trabajo.

No, no deberían comprometerse con el control de origen, ya que son configuraciones locales específicas del desarrollador / máquina.

GitHub mantiene una lista de tipos de archivos sugeridos para que los usuarios de Visual Studio ignoren en https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Para svn, tengo el siguiente global-ignoreconjunto de propiedades:

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
Debug
* .user
* .vshost. *
* .Tss
* .dbml.layout

Si establece sus dependencias de directorio ejecutable en ProjectProperties> Debugging> Environment , las rutas se almacenan en archivos '.user'.

Supongamos que configuro esta cadena en el campo mencionado anteriormente: "RUTA = C: \ xyz \ bin" Así es como se almacenará en el archivo '.user':

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

Esto nos ayudó mucho mientras trabajaba en OpenCV. Podríamos usar diferentes versiones de OpenCV para diferentes proyectos. Otra ventaja es que fue muy fácil configurar nuestros proyectos en una nueva máquina. Solo tuvimos que copiar los directorios de dependencia correspondientes. Entonces, para algunos proyectos, prefiero agregar '.user' al control de código fuente.

Aunque depende completamente de los proyectos. Puede atender una llamada según sus necesidades.

Como se ha explicado en otras respuestas, tanto .suoy .userno se debe añadir al control de origen, ya que son de usuario / máquina específica (por cierto .suopara las versiones más recientes de VS fue trasladado al directorio temporal dedicada .vs, que debe mantenerse fuera del control de código fuente completo).

Sin embargo, si su aplicación requiere alguna configuración de entorno para la depuración en VS (tales configuraciones generalmente se guardan en un .userarchivo), puede ser útil preparar un archivo de muestra (nombrándolo como .user.SAMPLE) y agregarlo al control de origen para referencias.

En lugar de una ruta absoluta codificada en dicho archivo, tiene sentido usar los relativos o confiar en variables de entorno, por lo que la muestra puede ser lo suficientemente genérica como para que otros la puedan reutilizar fácilmente.