c# - tortoise - svn plugin visual studio 2017
¿Por qué el código generado por el diseñador de C#(como Form1.designer.cs) hace estragos en Subversion? (5)
Mi taller ha cambiado recientemente a Subversion desde SourceSafe, liberándonos de bloqueos automáticos. Esto condujo a la edición simultánea de las Formas, lo cual es maravilloso. Pero cuando varios desarrolladores confirman sus cambios, los archivos de código creados por el diseñador (todos los archivos llamados TheFormName.designer.cs ) causan conflictos que son muy difíciles de resolver.
Por lo que puedo decir, esto se debe a que el código generado por el diseñador se reorganiza mucho cada vez que el usuario lo modifica, sin importar cuán poco realmente lo hizo el cambio real.
- ¿Cómo puedo hacer que estos conflictos sean más fáciles de resolver?
- ¿Hay alguna manera de decirle al diseñador que modifique el código menos?
- ¿Cómo se enfrentan ustedes, los equipos experimentados de C #, con la modificación simultánea de un formulario?
Aquí hay algunas cosas para probar:
- Haz las cosas más modulares. Use componentes como los Controles de usuario, etc. para dividir las formas en múltiples archivos físicos más pequeños.
- Use los patrones de diseño de la capa de presentación como MVP para mover el código de las vistas a las clases estándar de POCO.
- Las versiones recientes de SVN le permiten tomar bloqueos duros: use esto para evitar situaciones complejas de fusión.
Espero que ayude.
Estoy bastante seguro de que no hay una solución mágica para este problema, ya que el diseñador pisa todo el designer.cs.
Todo lo que puedo sugerir es minimizar el uso del diseñador. Personalmente, solo engancho eventos en código y solo uso el diseñador solo para inicialización y posicionamiento. Como tal, no es demasiado difícil de entender las diferencias en un conjunto de cambios ("oh, alguien ha agregado un botón", "oh, alguien ha cambiado la forma en que se ve un poco").
La única manera que conozco para evitar este problema cuando uso un sistema de control de fuente de estilo de fusión, como la subversión, es codificar manualmente los formularios y no usar el diseñador. Obviamente, esto no sería bueno porque la codificación manual de estas formas puede llevar un tiempo.
La razón por la que esto sucede es porque el diseñador serializa las propiedades de control en el orden en que se eliminan del formulario. Cortar y pegar puede afectar este orden, así como mover un control para que tenga un nuevo padre (como mover un control a un panel cuando estaba previamente directamente en el formulario).
Tuve este problema en un proyecto grande y tuve que implorar un enfoque bastante feo: diferir los archivos designer.cs contra la revisión de destino de check-in y combinarlos manualmente usando una herramienta de fusión. Esto no es ideal, pero es la única forma en que veo que esto funciona de forma consistente con svn u otra herramienta de control de fuente de estilo de fusión.
La otra opción sería usar un enfoque de bloqueo con control de fuente, como otros han señalado, pero esto también tiene efectos secundarios desagradables.
No estoy familiarizado con C # o Windows Form Designer, pero mirando algunos archivos designer.cs que pude encontrar en línea, no tienen una estructura particularmente complicada.
¿Qué partes están siendo reorganizadas? Supongo que es principalmente el orden de las propiedades en el método InitializeComponent() que está mezclado?
Si ese es el caso, es posible que pueda escribir un script simple que reordena esas líneas alfabéticamente, digamos (especialmente si nunca edita estos archivos manualmente de todos modos), y use eso como un script de enlace de precompilación en Subversion.
Um, claro ... rayar eso. La gran caja roja en la parte inferior de esa sección dice que no debes modificar transacciones en scripts de gancho. Pero es posible que pueda encontrar otra forma de ejecutar ese script en algún lugar entre el archivo designer.cs que se está modificando y el que se está confirmando.
Editar:
En realidad, dado el comentario de Scraimer sobre esto:
Total pirateo, pero en el peor de los casos, justo antes de una fusión, podía ordenar AMBOS archivos y hacer la fusión simplemente un asunto línea por línea ...
¿No puedes dejar que Subversion establezca un programa de fusión externo? He estado usando KDiff3 , que puede ejecutar un comando de preprocesador antes de hacer diffs o fusiones , para que pueda automatizar ese proceso.
Sí, la reorganización aleatoria del diseñador es irritante. ¿Microsoft usa sus propias herramientas? ¿Mira Microsoft lo que verifican en el control de versiones? Alucina la mente.
La "solución" de nuestro equipo es editar a mano los archivos de Designer una vez que hayamos terminado de editarlos, para volver a colocarlos donde estaban, de modo que la diferencia basada en texto sea legible y, por lo tanto, los cambios concurrentes se puedan fusionar de forma sana. Afortunadamente, la mayor parte de la reorganización de Visual Studio es simple, así que esto funciona.
Lamentablemente, hemos encontrado que este paso es necesario para verificar la corrección: hemos encontrado casos en los que el Diseñador elimina silenciosamente elementos que son necesarios, lo que da como resultado un código roto. Así que este paso debe hacerse para evitar cualquier error que destruya los datos que se esconden en su interior. Suspiro.
Dado que Microsoft tiene un pobre historial de reparación de errores, la única solución puede ser mejorar el Diseñador de WinForms de Mono para que esté listo para el horario de máxima audiencia.