visual-studio - tutorial - visual studio code español
¿Por qué tener carpetas separadas de depuración y lanzamiento en Visual Studio? (10)
Por supuesto, de forma predeterminada, Visual Studio crea carpetas bin separadas para las compilaciones Debug y Release. Estamos teniendo algunos problemas menores relacionados con aquellos desde la perspectiva de las dependencias externas, donde a veces queremos liberar binarios y a veces depurar. Haría la vida un poco más fácil si solo tuviera una única carpeta bin en todos los proyectos y fuera el objetivo tanto para Debug como para Release. Entonces podríamos apuntar nuestros scripts externos, etc. a una sola ubicación.
Un compañero de trabajo preguntó por qué no podíamos hacer eso: ¿cambiar la configuración del proyecto VS para ir a la misma carpeta bin? Confieso que realmente no pude pensar en una buena razón para mantenerlos, aparte de poder ver fácilmente en mi sistema de archivos local cuáles son Debug y cuáles son Release. Y qué; ¿Qué gana eso?
Mis preguntas):
- ¿Cómo aprovechas las distintas carpetas de depuración y lanzamiento? ¿Qué procesos habilita esto en tu desarrollo?
- ¿Qué mal puede pasar si no conservas esta distinción?
- A la inversa, si ha seguido la ruta de la "carpeta única", ¿cómo le ha ayudado esto?
No estoy preguntando por qué tienen versiones separadas de depuración y lanzamiento. Entiendo la diferencia, y el lugar de cada uno. Mi pregunta se refiere a colocarlos en carpetas separadas.
A mi modo de ver, esto es simplemente una comodidad en la máquina del desarrollador que les permite compilar y ejecutar las compilaciones de Depuración y Liberación simultáneamente.
Si tiene scripts o herramientas que se ejecutan dentro de Visual Studio, el IDE le permite usar el nombre de configuración y otras macros para obtener rutas que son independientes de la configuración.
Si está ejecutando scripts y herramientas externamente desde la línea de comandos (es decir, está estructurando algún tipo de lanzamiento o proceso de implementación a su alrededor), es mejor hacerlo en un servidor de compilación, donde la distinción entre Depurar y Liberar desaparece.
Por ejemplo, cuando invoca msbuild desde la línea de comandos (en el servidor de compilación), puede especificar la propiedad de configuración para depurar o lanzar, y la propiedad OutputPath para compilar solo en una ubicación (independientemente de la configuración).
Dave, si compilas Debug y Release en una sola carpeta, puedes encontrar la situación en la que algunos dll-s no se volverán a compilar después de cambiar de Release a Debug y viceversa, ya que los archivos dll serán más nuevos que los archivos de origen. Sí, la "Reconstrucción" debería ayudarlo, pero si olvida esto, puede tener algunas horas adicionales de depuración.
En una empresa anterior resolvimos este problema cambiando los nombres del ejecutable de depuración y los dlls agregando una "D". Asi que
MainProgram.exe y library.dll
volverse
MainProgramD.exe y libraryD.dll
Esto significa que podrían coexistir en la misma carpeta de salida y todos los scripts, rutas, etc. podrían simplemente hacer referencia a eso. Los archivos intermedios aún deben ir a carpetas separadas, ya que los nombres de estos no se pueden cambiar.
Obviamente, debe cambiar todas sus referencias para que apunten al nombre modificado para la depuración, algo que olvidará hacer en algún momento.
Las clases de IDE de Visual Studio funcionan mejor para la multitud. Crean la estructura por defecto del proyecto, carpetas binarias. Podría asignar los binarios a la carpeta única. Luego debe informar a los otros desarrolladores que los archivos de Liberación / Depuración se almacenan en la misma carpeta.
Los desarrolladores te preguntan, ¿a quién te gusta eso?
En VC ++, tenemos diferentes bibliotecas generadas y necesita vincular las versiones apropiadas. De lo contrario obtendrá un error del enlazador.
Normalmente compilo en modo de depuración, pero a veces necesito compilar en modo de lanzamiento. Desafortunadamente, no se comportan exactamente igual en ciertas situaciones de error. Al tener carpetas separadas, no necesito volver a compilar todo solo para cambiar los modos (y una recompilación completa de nuestras cosas en el modo Release tardará un poco).
Ocasionalmente, uno puede encontrarse con un problema de memoria no inicial particularmente desagradable que solo ocurre con una versión de lanzamiento. Si no puede mantener (como sugiere ChrisF) nombres separados para sus archivos binarios de depuración y versión, es realmente fácil perder la pista de qué binario está utilizando actualmente.
Además, puede encontrar ajustes en la configuración del compilador (es decir, el nivel de optimización, los símbolos de liberación con depuración para facilitar la creación de perfiles, etc.) y es mucho más fácil mantenerlos en orden con carpetas separadas.
Sin embargo, todo es una cuestión de preferencia personal, razón por la cual Visual Studio facilita el cambio de opciones.
Ser consistente en tus asambleas es algo bueno. No desea tratar problemas relacionados con la compilación condicional / etc. donde tus dlls de liberación y depuración son incompatibles, pero estás intentando ejecutarlos uno contra el otro.
Tengo una experiencia de proyecto algo más grande. Si hay pocas soluciones que utilicen referencias de archivos a otras soluciones, debe apuntar la referencia a UN directorio, por lo que, obviamente, tiene que ser el "lanzamiento" para la compilación continua / nocturna. Ahora puede imaginar lo que sucede si el desarrollador desea trabajar con versiones de depuración: todas las referencias apuntan a las de lanzamiento. Si apunta al mismo directorio, cambiar a depuración sería solo cuestión de volver a compilar todas las cosas relacionadas en el modo de depuración y las referencias de los archivos apuntarían automáticamente a las versiones de depuración desde entonces.
Por otro lado, no veo el motivo por el cual el desarrollador querría trabajar con versiones de lanzamiento (y cambiar de un lado a otro): el modo de lanzamiento solo es útil para las compilaciones completas / completas, por lo que las soluciones en VS pueden mantenerse. predeterminado en el modo de depuración, y la secuencia de comandos de compilación (de todos modos) siempre limpia, lanza la compilación.
Una razón por la que uso carpetas separadas es que garantiza que solo genero instaladores que usan el código Release-build. Utilizo WiX, que me permite especificar la ruta exacta a los archivos que quiero incluir en el instalador, por lo que termino especificando la ruta en la carpeta Release. (Por supuesto, puede hacer lo mismo con los instaladores VS normales, de modo que no es realmente el punto). Si olvida cambiar su proyecto a la Versión antes de compilar, el instalador no compila a menos que tenga un código antiguo en la Versión carpeta, en cuyo caso terminas con un instalador antiguo, por lo que es un escollo. La forma en que me desenvuelvo es usar el evento posterior a la compilación en el proyecto del instalador de WiX que borra la carpeta de la versión después de que se construye el instalador de WiX.
Lo que todos dicen sobre aspectos técnicos es importante. Otro aspecto es que puede encontrarse en condiciones de carrera si una compilación se basa en la compilación de ubicación de salida única, pero no hay sincronización entre las dos compilaciones. Si la primera compilación se puede volver a ejecutar (especialmente en un modo diferente) después de que comience la segunda compilación, realmente no sabrá si está utilizando una depuración de compilación de versión.
Y no olvide el aspecto humano: es mucho más fácil saber con qué está trabajando (y corregir construcciones dañadas) si las dos construyen salidas en diferentes ubicaciones.