Ventajas de usar MSBuild o NAnt versus ejecutar DevEnv.exe desde la línea de comandos
build-process (6)
La razón principal para usar una herramienta de compilación externa como NAnt o MsBuild es la capacidad de automatizar el proceso de compilación y así proporcionar retroalimentación continua sobre el estado de su sistema. También se pueden usar para muchas cosas además de una compilación "pura" y es allí donde realmente comienzas a obtener valor de ellas, es algo extremadamente valioso poder construir y probar tu aplicación con un solo comando.
También puede comenzar a agregar elementos como la recopilación de métricas, el empaque de los archivos binarios de publicación y todo tipo de cosas ingeniosas como esa.
¿Alguien puede explicar qué ventajas hay al usar una herramienta como MSBuild (o NAnt) para construir una colección de proyectos en lugar de ejecutar DevEnv.exe desde la línea de comandos?
Un colega con el que trabajé en el pasado me explicó que (al menos con versiones anteriores de Visual Studio) que usa DevEnv.exe era mucho más lento que las otras técnicas, pero no he leído ninguna evidencia de eso o si eso es ahora una punto discutible ahora que a partir de 2005, Visual Studio usa MSBuild bajo el capó.
Sé que una ventaja de utilizar MSBuild le permite construir sus proyectos sin requerir que Visual Studio esté instalado en las máquinas de compilación, pero no estaba seguro de si había otros.
Una razón es porque hay mucho más para construir un producto que simplemente compilarlo. Las tareas como crear instalaciones, actualizar números de versión, crear depósitos de garantía, distribuir los paquetes finales, etc. pueden ser mucho más fáciles debido a lo que proporcionan estas herramientas (y sus extensiones).
Si bien puede hacer todo esto con scripts regulares, el uso de NAnt o MSBuild le proporciona un marco sólido para hacer todo esto. Hay mucho apoyo de la comunidad para ambos, incluidas tareas adicionales que se pueden descargar (como el Proyecto de Tareas Comunitarias de MSBuild ). Además, hay soporte para ellos en numerosos productos de terceros y de código abierto.
Si solo está interesado en compilar (y no en todo el proceso de compilación), puede encontrar que el beneficio de MSBuild para ahorrar tiempo es el soporte para compilar con múltiples procesadores .
Estamos experimentando con el cambio de DevEnv a una herramienta (Visual Build Pro) que usa MsBuild bajo el capó y obtuvimos el error "Referencia requerida para ensamblar ''System.Drawing ..." para un proyecto que no lo necesita y que construye bien en Visual Studio.
La respuesta obvia de mi equipo es que Everbody no tiene instalado Visual Studio, en particular, no instalamos Visual Studio en nuestros servidores de compilación / CI.
En lo que se refiere a C #, devenv.exe 2005 ejecuta el compilador in-proc, lo que puede causar excepciones de falta de memoria para soluciones considerables. Msbuild recurre al lanzamiento del proceso csc.exe para cada proyecto. Los proyectos que no compilan con devenv / build funcionan bien con msbuild. Espero que te guste este motivo.
Tenemos un gran sistema que consiste en C #, C ++ administrado y ensamblajes / dlls C ++ no administrados y antiguos. Hay un código de C ++ que depende del código de C ++ administrado que depende del código de C # que depende del código de C ++ administrado que depende del código antiguo de C ++ (¡oh!). Cuando estábamos configurando nuestro entorno de compilación automatizado hace unos años, descubrimos que MSBuild.exe no manejaba correctamente todas las dependencias que tenemos.
Al trabajar con Microsoft, pudimos resolver algunos de los problemas, pero no todos. Si mi memoria me sirve, nunca podríamos obtener ensamblajes de C # que dependieran de dlls administrados de C ++ para compilar. Así que terminamos creando un script de compilación personalizado que llamó devenv.exe desde la línea de comandos y funcionó bien.
Por supuesto, eso fue con VS2005, podría arreglarse ahora, pero la secuencia de comandos todavía funciona, por lo que no hemos revisado el problema.