VS2008 y ClearCase: la solución de apertura solicita un proceso de pago sin ningún motivo

Question

Tengo un pequeño problema que hace que mis compilaciones automatizadas se caigan.

Cuando abrimos una solución convertida recientemente de VS2005 a VS2008 VS a través de ClearCase, solicitamos que verifiquemos el archivo de la solución.

Si lo permitimos, no se realizan cambios de todos modos y, de forma predeterminada, a ClearCase no le gustan los registros sin cambios. Así que deshacemos el proceso de pago, y desde ese momento VS está contento, pudo escribir el archivo .suo.

Si dejamos de leer, protegemos el archivo de la solución, iniciamos el VS2008, creará el archivo .suo, si luego deshacemos el archivo .sln (sin cambios, así que el VS2008 no se da cuenta) y reiniciamos el VS2008 está bien, no solicita un pago.

En mi script de compilación, elimino todos los archivos privados de la vista y luego hago una actualización con el desguace forzado de archivos controlados. Y luego construimos los proyectos de implementación (y, por lo tanto, todas las dependencias) y, a medida que se elimina el archivo .suo, cae en el comportamiento del archivo .sln de verificación cada vez.

Y en el servidor de compilación no hay nadie alrededor para ver el cuadro de diálogo que solicita una comprobación, la compilación se bloquea.

Podría cambiar (también conocido como bodge) el script de compilación para no eliminar el archivo .suo, pero preferiría no hacerlo.

edite: aclaración: el archivo .suo NO está registrado en ClearClase; es un archivo privado de vista creado por VS2008; sin embargo, para crear este archivo desea revisar el archivo .sln por una razón no real.

Edición adicional:

Encontré la solución a esto: deshabilité la integración según mi publicación de seguimiento en este hilo.

Answer 1

Bueno, encontré la solución al problema y en realidad era bastante simple.

Deshabilité la integración de Visual Studio ClearCase en el servidor de compilación.

VS se está utilizando, ya que necesitamos crear proyectos de implementación, por lo que llamamos a devenv para que haga esto por nosotros. Sin embargo, solo lo estamos utilizando como motor de compilación, nunca es necesario que el motor de compilación sepa cómo modificar los elementos de origen, ya que todos ellos simplemente provendrán de ClearCase. Los únicos elementos que permitimos que el servidor de compilación modifique son los atributos del número de versión del archivo de ensamblaje en los archivos de AssemblyInfo, pero lo hacemos en el NAnt y no en Visual Studio.

Entonces, deshabilita la funcionalidad y el problema desaparece. Probablemente no sea la solución para todos, pero en un servidor de compilación fue el camino a seguir.

Answer 2

Este elemento de solución de problemas , tengo Me dirijo a este paquete de arreglos que resolvió el problema en nuestro entorno de desarrollo. Seguimos usando VS2005, pero espero que sea el mismo problema que lo que salió mal en VS2008.

Answer 3

Esto parece ser normal para VS2008, comprueba el archivo .sln al abrir una solución. Tampoco me gusta.

Sin embargo, su problema es el hecho de que el archivo .suo también está registrado. Este archivo no debe colocarse bajo el control de código fuente. Es como los archivos proj.user. Sospecho que suo significa Opciones de usuario de la solución.

Answer 4

Podrías:

• actualice su secuencia de comandos para secuestrar el archivo sln en su vista instantánea justo después de su " cleartool update -force -overwrite " ;.
• o, para evitar la extracción de la sln, puede intentar mantener la archivo. suo registrado,

Si la sugerencia anterior funciona, aquí hay un par de razones por las que uno querría mantener este archivo bajo el control de versiones:

• Desde El archivo .suo es desechable (VS2008 simplemente crea uno nuevo si no existe), el control bajo código fuente puede ser visto como una forma de evitar esa creación (evitando que el complemento ClearCase lo detecte e intente " Añádalo al control de origen "

• Otra ventaja de tener el archivo .suo bajo el control de versión (pero no actualizado a través de cualquier otra verificación / registro) es cuando esté comparando su proyecto desprotegido con otra versión desprotegida del mismo proyecto descargado en otro lugar: ese archivo siempre será idéntico, en lugar de sistemáticamente diferente (ya que si es un archivo binario, y cualquier nueva versión de un archivo binario se registraría como diferente)