Compilar solución de Visual Studio en paralelo
Oscar E. Fraxedas Tormo
Hola a todos,
En mi equipo tenemos una solución en VS2008, de 45 proyectos, divididos en proyectos de código, mergemodules y setup. El código es VB y C#, no tenemos nada en C++. Los 45 proyectos quedaron luego de un refactoring donde reducimos la cantidad de proyectos. La dependencia entre los proyectos no es muy lineal, por lo que admiten paralización, sobre todo lo de setup.
Esta solución se compila (rebuild) por cada commit en el servidor de integración continua (TeamCity+VBPro) llamando a VS (no a msbuild) por la línea de comando. Al tener tantos proyectos la compilación se demora bastante y estamos tratando de optimizar el tiempo de compilación. A la maquina donde se corre el build se le puede dar mas de un micro, pues esta virtualizada.
La pregunta: ¿Es posible compilar los proyectos en paralelo? ¿Alguien ha probado esto?
Estuve mirando opciones pero no he avanzado mucho:
· En VS Tools | Options | Projects and Solutions | Build and Run | maximum number of parallel projects builds: Esto tiene el numero de cores de la maquina.
· /MP (http://msdn.microsoft.com/en-us/library/bb385193.aspx): solo sirve para msbuild, VS no lo acepta desde la línea de comando.
Recuerdo hace años que en el mundo Linux existía distcc (http://en.wikipedia.org/wiki/Distcc). ¿Alguien ha usado algo similar en .NET?
saludos y gracias por adelantado,
Oscar Fraxedas
Erlis Vidal
Pregunta Oscar:
Usualmente el problema de MSBuild es que el projecto Setup (el vdproj) no se puede compilar pues no esta soportado, por lo tanto tienes que ejecutar el VS pasandole parametros para poder compilar el Setup project.
Mi pregunta es, han experimentado compilar el proyecto con MSBuild y luego compilar solo el installer con el VS como lo hacen ahora?
Esto no lo he probado pero puede que funcione.
Salu2
Erlis
Oscar E. Fraxedas Tormo
Hola Erlis,
Usamos VS para compilar en el CI precisamente por los Setup projects. También tratamos de replicar el mismo ambiente en el CI que en la máquina de los desarrolladores, para concentrar los esfuerzos y no tener que hacer la solución compatible para 2 build runners.
De todas formas, si no encontramos una solución con deven evaluaremos migrar a msbuild.
saludos y gracias,
Oscar Fraxedas
Román Fresneda Quiroga
Oscar E. Fraxedas Tormo
Hola Roman,
El caso es que tenemos 2 soluciones:
· Working: solo tienes los proyectos de código. Demora 6 min en CI.
· Setup: tiene los proyectos de código y los de setup. Demora 17 min en CI.
Es necesario correr ambas soluciones para estar seguro de que están en sincronía.
Además de eso se corren los unit tests, demoran 9 min en CI.
Las soluciones siempre se compilan haciendo rebuild.
Eso sumado a otras pequeñeces hace que el build se demora alrededor de 40 min.
En caso de que encuentre algo lo hare saber.
Oscar E. Fraxedas Tormo
Hola a todos,
Luego de googlear y probar con VS, MSBuild, TeamCity y VisualBuildPro fue posible bajar un poco el tiempo total del build.
Para poder compilar la solución usando MSBuild fue necesario adicionar algunas referencias a librerías del sistema y a proyectos que VS podía resolver, pero MSBuild no encontraba.
Se puede adicionar MSBuild como external tool de VS usando la siguiente configuración:
· Comando: C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
· Argumentos: $(SolutionFileName) /t:build /p:Configuration=Release "/p:Platform=Any CPU" /v:normal /m
· Directorio inicial: $(SolutionDir)
Los errores no se muestran en el “Error List”, pero pinchando en “Output” VS te lleva a la línea de código correspondiente.
El parámetro /m activa el uso de múltiples cores, se debe usar como /m:MaxCoresToUse, pero con solo poner /m se activaron 4 procesos de MSBuild en mi máquina (i5). Para un mejor control de esta opción se puede usar con la variable de sistema /m:%NUMBER_OF_PROCESSORS%.
La principal diferencia la causa el tipo de la compilación: build vs rebuild. El nivel de logging de MSBuild afecta en menor medida, pero se pueden ganar algunos segundos adicionales usando /v:quiet, solo a veces vi una diferencia que justifique la falta de logging, así que lo dejé en normal.
Para la compilación que corre en el CI quedo la siguiente configuración:
· Solución de Working (solo código): Compilar usando MSBuild con paralelismo activado.
· Solución de Setup (código+setup): Compilar usando VS pero haciendo build en lugar de rebuild.
Gracias Erlis por la recomendación, funciona OK.
Antes de cada compilación ajustábamos en número de versión en cada AssemblyInfo, lo cual no hacia diferencia entre un build y un rebuild, pues se tocaban todos los proyectos. Esto fue eliminado.
La compilación de los proyectos de Setup sigue consumiendo gran parte del tiempo. Vamos a probar Wix (gracias Roman) como reemplazo de los setup project de VS. El build runner que usamos (Visual Build Pro) tiene soporte para Wix, lo cual nos ayuda bastante.
La idea es dejar el build que hacemos por cada commit por debajo de 10 minutos. Todavía nos queda bastante trabajo por hacer para llegar ahí.
Gracias a todos por la ayuda.
regards, Oscar Fraxedas
Erlis Vidal
Una cosita con respecto a WiX.
Te pudiera decir el tipo de instaladores se dividen en 2, imperativos y declarativos. Todo depende de la tecnologia que quieras utilizar, .MSI vs .EXE. Hay casos en que no tienes opcion, por ejemplo en mi trabajo es obligatorio entregar un .MSI, pues quieren hacer un deploy del mismo utlizando Group Policy Objects (GPO) que es algo que no se puede hacer con instaladores .EXE
A partir de este punto tienes dos caminos a escoger, la forma declarativa donde WiX es lo que te recomendaria, y la forma imperativa, aqui te recomendaria Inno Setup, pues es muy facil de utilizar, open source y con muy buena documentacion, lo que mas me gusto es que el lenguaje que usa es Pascal, a diferencia de otros como NSIS por ejemplo que se acerca mas a ensamblador (si ensamblador, push, pop etc)
Con esto dicho, suerte y espero que sepas que cualquier camino que escojas tiene su "learning curve" todo depende de cuan complejo es el instalador.
Salu2 y gracias una vez mas
Erlis
http://www.jrsoftware.org/isinfo.php
Oscar E. Fraxedas Tormo
Hasta el momento solo hemos trabajado con msi y los proyectos de Setup y MergeModule de VS. Para algunas tareas como iniciar y detener servicios tenemos que complementar escribiendo directamente en el msi, usando scripts en post-build y auxiliandonos de orca para verificar.
Por ahora vamos a seguir un tiempo m�s con los Setup de VS, hasta un beta estable, pero eventualmente migrar�amos.
Gracias por todo.
On 05/12/2011 11:24, Erlis Vidal wrote:
Gracias a ti Oscar por resumirnos tu experiencia!
Una cosita con respecto a WiX.
Te pudiera decir el tipo de instaladores se dividen en 2, imperativos y declarativos. Todo depende de la tecnologia que quieras utilizar, .MSI vs .EXE. Hay casos en que no tienes opcion, por ejemplo en mi trabajo es obligatorio entregar un .MSI, pues quieren hacer un deploy del mismo utlizando Group Policy Objects (GPO) que es algo que no se puede hacer con instaladores .EXE
A partir de este punto tienes dos caminos a escoger, la forma declarativa donde WiX es lo que te recomendaria, y la forma imperativa, aqui te recomendaria Inno Setup, pues es muy facil de utilizar, open source y con muy buena documentacion, lo que mas me gusto es que el lenguaje que usa es Pascal, a diferencia de otros como NSIS por ejemplo que se acerca mas a ensamblador (si ensamblador, push, pop etc)
Con esto dicho, suerte y espero que sepas que cualquier camino que escojas tiene su "learning curve" todo depende de cuan complejo es el instalador.
Salu2 y gracias una vez mas
Erlis
http://www.jrsoftware.org/isinfo.php
2011/12/5 Oscar E. Fraxedas Tormo <frax...@gmail.com>
Hola a todos,
Luego de googlear y probar con VS, MSBuild, TeamCity y VisualBuildPro fue posible bajar un poco el tiempo total del build.
Para poder compilar la soluci�n usando MSBuild fue necesario adicionar algunas referencias a librer�as del sistema y a proyectos que VS pod�a resolver, pero MSBuild no encontraba.
Se puede adicionar MSBuild como external tool de VS usando la siguiente configuraci�n:
��������� Comando: C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
��������� Argumentos: $(SolutionFileName) /t:build /p:Configuration=Release "/p:Platform=Any CPU" /v:normal /m
��������� Directorio inicial: $(SolutionDir)
Los errores no se muestran en el �Error List�, pero pinchando en �Output� VS te lleva a la l�nea de c�digo correspondiente.
El par�metro /m activa el uso de m�ltiples cores, se debe usar como /m:MaxCoresToUse, pero con solo poner /m se activaron 4 procesos de MSBuild en mi m�quina (i5). Para un mejor control de esta opci�n se puede usar con la variable de sistema /m:%NUMBER_OF_PROCESSORS%.
La principal diferencia la causa el tipo de la compilaci�n: build vs rebuild. �El nivel de logging de MSBuild afecta en menor medida, pero se pueden ganar algunos segundos adicionales usando /v:quiet, solo a veces vi una diferencia que justifique la falta de logging, as� que lo dej� en normal.
Para la compilaci�n que corre en el CI quedo la siguiente configuraci�n:
��������� Soluci�n de Working (solo c�digo): Compilar usando MSBuild con paralelismo activado.
��������� Soluci�n de Setup (c�digo+setup): Compilar usando VS pero haciendo build en lugar de rebuild.
Gracias Erlis por la recomendaci�n, funciona OK.
Antes de cada compilaci�n ajust�bamos en n�mero de versi�n en cada AssemblyInfo, lo cual no hacia diferencia entre un build y un rebuild, pues se tocaban todos los proyectos. Esto fue eliminado.
La compilaci�n de los proyectos de Setup sigue consumiendo gran parte del tiempo. Vamos a probar Wix (gracias Roman) como reemplazo de los setup project de VS. El build runner que usamos (Visual Build Pro) tiene soporte para Wix, lo cual nos ayuda bastante.
La idea es dejar el build que hacemos por cada commit por debajo de 10 minutos. Todav�a nos queda bastante trabajo por hacer para llegar ah�.
Gracias a todos por la ayuda.
On 01/12/2011 12:07, Oscar E. Fraxedas Tormo wrote:
Hola Roman,
El caso es que tenemos 2 soluciones:
��������� Working: solo tienes los proyectos de c�digo. Demora 6 min en CI.
��������� Setup: tiene los proyectos de c�digo y los de setup. Demora 17 min en CI.
Es necesario correr ambas soluciones para estar seguro de que est�n en sincron�a.
Adem�s de eso se corren los unit tests, demoran 9 min en CI.
Las soluciones siempre se compilan haciendo rebuild.
Eso sumado a otras peque�eces hace que el build se demora alrededor de 40 min.
En caso de que encuentre algo lo hare saber.
On 30/11/2011 19:28, Rom�n Fresneda Quiroga wrote:
Y cuanto se demoran esos 45 proyectos en compilar en el CI?
�En mi equipo tenemos una soluci�n que tiene 110 proyectos(+6000 unit tests)� y no se demora tanto (A lo sumo 15 mins cuando lo hacemos desde cero, unos 3-4 cuando solo han cambiado un par de ellos)�A proposito, en otra pinchita en que estuve,� usabamos WiX para evitar los feos proyectos de setup de VS, y como bonus, Wix se puede invocar desde msbuild con custom tasks.�En cuanto encuentres algo, y sobre todo si reduce dram�ticamente el tiempo de compilaci�n, haznoslo saber! Bonus si es con msbuild y no VS!
�
2011/11/30 Oscar E. Fraxedas Tormo <frax...@gmail.com>
Hola Erlis,
Usamos VS para compilar en el CI precisamente por los Setup projects. Tambi�n tratamos de replicar el mismo ambiente en el CI que en la m�quina de los desarrolladores, para concentrar los esfuerzos y no tener que hacer la soluci�n compatible para 2 build runners.
De todas formas, si no encontramos una soluci�n con deven evaluaremos migrar a msbuild.
On 30/11/2011 12:57, Erlis Vidal wrote:
Hmmm recuerdo hace un tiempo haber hecho algo de esto, pero ahora que lo dices no estoy seguro si la parte paralela la haciamos con MSBuild.
Pregunta Oscar:
Usualmente el problema de MSBuild es que el projecto Setup (el vdproj) no se puede compilar pues no esta soportado, por lo tanto tienes que ejecutar el VS pasandole parametros para poder compilar el Setup project.
Mi pregunta es, han experimentado compilar el proyecto con MSBuild y luego compilar solo el installer con el VS como lo hacen ahora?
Esto no lo he probado pero puede que funcione.
Salu2
Erlis
2011/11/30 Oscar E. Fraxedas Tormo <frax...@gmail.com>
Hola a todos,
En mi equipo tenemos una soluci�n en VS2008, de 45 proyectos, divididos en proyectos de c�digo, mergemodules y setup. El c�digo es VB y C#, no tenemos nada en C++. Los 45 proyectos quedaron luego de un refactoring donde reducimos la cantidad de proyectos. La dependencia entre los proyectos no es muy lineal, por lo que admiten paralizaci�n, sobre todo lo de setup.
Esta soluci�n se compila (rebuild) por cada commit en el servidor de integraci�n continua (TeamCity+VBPro) llamando a VS (no a msbuild) por la l�nea de comando. Al tener tantos proyectos la compilaci�n se demora bastante y estamos tratando de optimizar el tiempo de compilaci�n.� A la maquina donde se corre el build se le puede dar mas de un micro, pues esta virtualizada.
La pregunta: �Es posible compilar los proyectos en paralelo? �Alguien ha probado esto?
Estuve mirando opciones pero no he avanzado mucho:
��������� En VS Tools | Options | Projects and Solutions | Build and Run | maximum number of parallel projects builds: Esto tiene el numero de cores de la maquina.
��������� /MP (http://msdn.microsoft.com/en-us/library/bb385193.aspx): solo sirve para msbuild, VS no lo acepta desde la l�nea de comando.
Recuerdo hace a�os que en el mundo Linux exist�a distcc (http://en.wikipedia.org/wiki/Distcc). �Alguien ha usado algo similar en .NET?
--
saludos y gracias por adelantado,
Oscar Fraxedas
--
saludos y gracias,
Oscar Fraxedas
--
saludos y gracias,
Oscar Fraxedas
--
regards, Oscar Fraxedas
regards, Oscar Fraxedas