Visual Studio Bindings – Bound y unbound sc en diferentes soluciones

Tengo un equipo de desarrollo dividido en mentalidad de usar enlaces de control de fuente de Visual Studio. A la mitad le gustaría la integración y la otra mitad no. ¿Hay alguna manera de agregar una configuration de vinculación de solo solución para que cada equipo pueda usar una solución diferente según sus preferences?

No hay una solución indolora a este problema. La razón es que Microsoft tomó la monumental mala decisión de incorporar la información de control de origen en la solución .NET y los files del proyecto.

Digamos que Dick quiere usar el plugin SCC y Jane no. Dick agrega un proyecto al control de versiones a través del complemento y la información como esta se escribirá en el file de la solución:

GlobalSection(SourceCodeControl) = preSolution SccNumberOfProjects = 2 SccLocalPath0 = . SccProjectUniqueName1 = someApp\\someApp.csproj SccLocalPath1 = someApp EndGlobalSection 

y algo de basura como esta se agregará a los files de proyecto (s):

 <SccProjectName>SAK</SccProjectName> <SccLocalPath>SAK</SccLocalPath> <SccAuxPath>SAK</SccAuxPath> <SccProvider>SAK</SccProvider> 

Además, se distribuirán algunos files sobre el tree de carpetas del proyecto (files MSSCCPRJ.SCC en las carpetas de solución y proyecto, un * .vssscc en la carpeta de la solución y * .vspscc en las carpetas del proyecto).

Los files adicionales no son un problema, siempre y cuando Dick no los controle en el control de código fuente (aunque el complemento siempre va a querer verificar esos files .vssscc y .vspscc). Sin embargo, la información de control de origen que se escribe en la solución y en los files del proyecto siempre será una molestia para Jane. Cada vez que abre la solución, ella será molestada por este post:

enter image description here

y luego este:

enter image description here

Si elige la opción de "Eliminar permanentemente los enlaces de asociación de control de origen", la información de control de origen se eliminará de los files de solución y proyecto y ella estará contenta de nuevo. Sin embargo, el complemento SCC de Dick ya no funcionará y probablemente reenlace los proyectos al control de la fuente y se producirá un disturbio en la oficina.

Para resumir, puede compartir el proyecto .NET entre aquellos que usan el plugin SCC y aquellos que no lo hacen, pero una o más partes tendrán que soportar algunas molestias porque Microsoft decidió agregar información de control de fuente al proyecto .NET files (una mala decisión, esto no fue un problema en Visual Studio 6).

No estoy del todo seguro de si te entendí bien. Supongo que la mitad de tu equipo quiere usar el plugin de Visual Studio para acceder a Perforce y la otra mitad no.

Esto es posible. Debe asegurarse de nunca verificar el file MSSCCPRJ.SCC creado por el complemento. Esta es la información de enlaces locales y no funcionará en la estación de trabajo de todos.

Por otro lado, los files * .vssscc pueden y deben entrar en Perforce.

Sin embargo, usar el complemento tiene una gran ventaja: el complemento sabe qué files registrar y cuáles omitir. Especialmente cuando se agregan nuevos proyectos, es un error común olvidar registrar los files recién creados cuando se usa el cliente visual de Perforce en lugar del plugin.

Debe asegurarse de nunca verificar el file MSSCCPRJ.SCC creado por el complemento.

Eliminé los files * .scc, pero Visual Studio me impidió usar otros complementos de Source Controls, excepto los guardados en los files de solución y proyecto.