visual-studio generar - Diferencia entre Rebuild y Clean+Build en Visual Studio




compiler release (5)

Reconstruir = Limpiar + Construir

Detalles notables:

  1. Para una solución de proyectos múltiples, la "solución de reconstrucción" hace una "limpieza" seguida de una "construcción" para cada proyecto (posiblemente en paralelo). Mientras que una "solución limpia" seguida de una "solución de compilación" primero limpia todos los proyectos (posiblemente en paralelo) y luego construye todos los proyectos (posiblemente en paralelo). Esta diferencia en la secuencia de eventos puede ser significativa cuando las dependencias entre proyectos entran en juego.

  2. Las tres acciones corresponden a los objetivos de MSBuild. Por lo tanto, un proyecto puede anular la acción Reconstruir para hacer algo completamente diferente.

¿Cuál es la diferencia entre solo una Reconstrucción y hacer un Clean + Build en Visual Studio 2008? ¿Es Clean + Build diferente que Clean + Rebuild ?


1 Por proyecto, Reconstruir proyecto = (Proyecto limpio + Proyecto de compilación).

2 por solución, ¡Reconstruir Sln = proyecto foreach (proyecto limpio + proyecto de compilación)! = Sln limpio + Build Sln

Digamos que tienes un Sln, contiene proj1, proj2 y proj3.

Rebuild Sln = (Clean proj1 -> Build Proj1) + (Clean proj2 -> Build Proj2) + (Clean proj3 -> Build Proj3)

Clean Sln + Build Sln = (Clean proj1 + Clean proj2 + Clean proj3) -> (Build proj1 + Build proj2 + Build proj3)

-> significa serial, + significa concurrente

así que existe la posibilidad de que cuando envíes muchos cambios de código mientras no configuras correctamente las dependencias del proyecto, Rebuild Sln causará que algunos de ustedes proyecten un enlace a una biblioteca obsoleta porque no se garantiza que todas las compilaciones se realicen después de todo. En este caso, Clean Sln + Build Sln generará un error de enlace y le informará de inmediato, en lugar de proporcionarle una aplicación con un comportamiento extraño.


Earl tiene razón en que el 99% del tiempo Rebuild = Clean + Build.

Pero no se garantiza que sean iguales. Las 3 acciones (reconstruir, construir, limpiar) representan diferentes objetivos de MSBuild. Cada uno de los cuales puede ser reemplazado por cualquier archivo de proyecto para realizar acciones personalizadas. Por lo tanto, es completamente posible que alguien anule la reconstrucción para realizar varias acciones antes de iniciar una compilación limpia (o eliminarlas por completo).

Es un caso de esquina, pero lo señalo debido a las discusiones de comentarios.


De esta publicación de blog que el autor vinculó como comentario sobre esta pregunta :

¡¡¡En realidad no!!! no son iguales

La diferencia está en la secuencia de proyectos de limpiar y construir. Digamos que tenemos dos proyectos en una solución. Limpiar y luego construir generará resultados limpios para ambos proyectos y luego la compilación ocurrirá individualmente mientras que en el proyecto de reconstrucción A se limpiará y luego se construirá después de que el proyecto B esté limpio y luego se construya, y así sucesivamente.


Esta parece ser la opinión de Microsoft al respecto:

Agregar (y editar) archivos .suo al control de origen

No sé por qué su proyecto almacena el DebuggingWorkingDirectory en el archivo suo. Si esa es una configuración específica del usuario, debe considerar almacenarla en el nombre de archivo * .proj.user. Si esa configuración se puede compartir entre todos los usuarios que trabajan en el proyecto, debe considerar almacenarlo en el archivo del proyecto.

¡Ni siquiera pienses en agregar el archivo suo al control de código fuente! El archivo SUO (opciones de usuario soluton) está diseñado para contener configuraciones específicas del usuario y no debe compartirse entre los usuarios que trabajan en la misma solución. Si agregaría el archivo suo a la base de datos de scc, no sé qué otras cosas en el IDE rompería, pero desde el punto de vista del control de origen romperá la integración de scc de los proyectos web, el complemento Lan vs Internet utilizado por diferentes usuarios para el acceso a VSS, e incluso podría causar que el scc se rompa completamente (la ruta de la base de datos de VSS almacenada en un archivo suo que puede ser válida para usted puede no ser válida para otro usuario).

Alin Constantin (MSFT)





visual-studio visual-studio-2008 build rebuild