TFS 2008, elimine el file del control de origen pero déjelo en el proyecto

Estamos utilizando la sugerencia de Scott Hansleman para múltiples web.configs de su publicación aquí . El problema que tenemos es que tenemos que verificar la Web.Config. Si lo eliminamos del proyecto, cuando lo publiquemos, no se empujará web.config. Por lo tanto, debemos eliminar los enlaces de control de origen solo desde web.config, pero dejarlo en el proyecto y tener el rest del proyecto bajo control de fuente.

El problema es que el control de fuente hace que el file solo sea leído hasta que lo verifique. Necesitamos poder sobreescribirlo con los events de preconstrucción, preferiblemente sin tener que verificarlo. ¿Hay alguna forma de eliminar los enlaces de ese file solamente y aún así dejarlo como parte del proyecto?

Gracias.

Al agregar un nuevo file al explorador de soluciones, obtendrá el pequeño signo más que indica que se debe agregar al control de origen. A continuación, haga clic con el button derecho y elija "deshacer cambios pendientes". Esto cancelará el agregado pero dejará el file en su proyecto.

Si eso no funciona, sugiero uno de los siguientes methods:

  • Use la tarea Attrib del proyecto MSBuild Community Tasks para eliminar el indicador de solo lectura.
  • Use la tarea Exec en MSBuild para invocar tf.exe y extraer el file.

Debe dejar el file en control de fuente. De lo contrario, te encontrarás con varios problemas:

  • los cambios no serán versionados. 'dijo nuf.
  • no se puede ramificar ni fusionar, aunque web.config es uno de los files que tiene más probabilidades de variar entre entornos de desarrollo / testing / producción paralelos
  • los cambios que realice localmente no se propagarán a los compañeros de trabajo sin soluciones manuales
  • los desarrolladores que configuran un entorno por primera vez no obtendrán el file en absoluto
  • Team Builds no contendrá el file, al igual que sus implementaciones. (¿Seguro que no estás implementando directamente desde el escritorio ?!)

Tenga en count que el estado de los files individuales se almacena por completo en el server TFS. ('tf properties' descarga estos metadatos si tiene curiosidad) Solo los proyectos y soluciones tienen enlaces realmente escritos en el file. E incluso esas son inputs falsas que le dicen a VS "no se preocupe por mí, solo pregúntele a TFSProvider, sabrá quién soy y dónde se supone que debo estar". Si bien hay muchas otras peculiaridades en el sistema de proyectos de VS que me dan dolores de cabeza interminables, en este caso es tu amigo. No lo evites.

Las mejores opciones:

  1. Edite su script de compilation para alternar el atributo de solo lectura antes / después de la modificación. Si está utilizando el script "copyifnewer.bat" de la publicación de blog vinculada, literalmente debe ser una línea adicional. Incluso si desea mantener las cosas totalmente declarativas dentro del file make de MSBuild, apenas funciona con la ayuda de tareas de terceros .

  2. Use la function Archivo -> Control de fuente -> Excluir. Después de aplicar esta configuration, el file permanece bajo el control de la fuente, pero ya no estará sujeto a transferencias / comprobaciones automáticas por la solución activa. En otras palabras, puede editar el file de forma local al contenido de su corazón sin afectar a nadie más, pero si desea confirmar (o archivar) sus cambios, deberá hacerlo desde el Explorador de control de código fuente o desde la línea de command.

La opción n. ° 1 tiene la ventaja de ser una solución muy rápida para su configuration existente. La desventaja proviene de mantener varias copys de web.config. * La misma razón por la que copyr / pegar el código es malo: si cambias uno, tienes que cambiar todos los demás, o peor, olvidarlos y dejarlos fuera de sincronía hasta errores extraños te obligan a revisar el problema. Esto se podría mejorar cambiando el process para que solo haya 1 web.config "maestro" y las copys adicionales solo contengan diferencias (a través de un motor de diferencias textuales, transformaciones XSLT, manipulación programática en Powershell, etc.). Por supuesto, eso es más trabajo.

La opción # 2 evita los problemas del # 1 con muy poca sobrecarga. (El process de ingeniería en sí mismo no se modifica, solo la diferencia es la forma en que se comporta la UI de Visual Studio). Esta ventaja es fundamental si realiza cambios en web.config con frecuencia. Lo malo es que no hay una forma incorporada de rastrear variaciones en el file "maestro". Si las únicas diferencias son muy simples, por ejemplo, una cadena de connection o dos, puede que le resulte más fácil quedarse con un solo "maestro" y dejar que las personas realicen cambios ad hoc en sus máquinas de desarrollo. Incluso hay herramientas para hacer esto por usted, como Proyectos de implementación web (fácil) y la Herramienta de implementación de IIS (compleja). ¡En cualquier caso, su implementación real debería ser automática y estar controlada por la fuente, por supuesto! Si se requieren personalizaciones más pesadas de las que estas herramientas son capaces, entonces probablemente querrá el enfoque maestro híbrido + transformación descrito anteriormente.