Ventajas de usar MSBuild o NAnt en lugar de ejecutar DevEnv.exe desde la línea de comandos

Question

¿Puede alguien explicar qué ventajas tiene usar una herramienta como MSBuild (o NAnt) para crear una colección de proyectos en lugar de ejecutar DevEnv.exe desde la línea de comandos?

Un colega con el que había trabajado en el pasado había explicado que (al menos con versiones anteriores de Visual Studio) el uso de DevEnv.exe era mucho más lento que las otras técnicas, pero no he leído ninguna evidencia de eso o si eso ahora es un punto discutible ahora que a partir de 2005, Visual Studio usa MSBuild debajo del capó.

Sé que una ventaja de usar MSBuild le permite compilar sus proyectos sin necesidad de instalar Visual Studio en las máquinas de compilación, pero no estaba seguro de si había otros.

Answer 1

Una razón es que compilar un producto es mucho más que compilar. Las tareas como crear instalaciones, actualizar números de versión, crear escrows, distribuir los paquetes finales, etc. pueden ser mucho más fáciles debido a lo que ofrecen estas herramientas (y sus extensiones).

Si bien puede hacer todo esto con scripts regulares, usar NAnt o MSBuild le brinda un marco sólido para hacer todo esto. Hay una gran cantidad de apoyo comunitario para ambas, incluidas las 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 un beneficio de ahorro de MSBuild en soporte para construir con múltiples procesadores .

Answer 2

La respuesta obvia de mi equipo es que no todo el mundo tiene instalado Visual Studio , en particular no instalamos Visual Studio en nuestros servidores de compilación / CI.

Answer 3

La razón principal para usar una herramienta de compilación externa como NAnt o MsBuild es la capacidad de automatizar su proceso de compilación y, por lo tanto, proporcionar retroalimentación continua sobre el estado de su sistema. También se pueden usar para un montón de cosas además de un " puro " construir y ahí es donde realmente empiezas a obtener valor de ellos, es una cosa extremadamente valiosa poder construir y probar tu aplicación con un solo comando.

También puedes comenzar a agregar elementos como la recopilación de métricas, el empaquetado de binarios de lanzamiento y todo tipo de cosas ingeniosas como esa.

Answer 4

En lo que respecta a C #, devenv.exe 2005 ejecuta el compilador in-proc, lo que puede causar excepciones de memoria para soluciones considerables. Msbuild recurre al inicio del proceso csc.exe para cada proyecto. Los proyectos que no se compilan con devenv / build funcionan bien con msbuild. Espero que te guste esta razón.

Answer 5

Estamos experimentando con el cambio de DevEnv a una herramienta (Visual Build Pro) que usa MsBuild debajo del capó y obtuvimos una " Referencia requerida para ensamblar 'System.Drawing ... " error para un proyecto que no lo necesita y que funciona bien en Visual Studio.

Answer 6

Tenemos un gran sistema que consta de C #, C ++ administrado y ensamblajes / dlls de C ++ no administrados antiguos y sencillos. Existe 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 de C ++ antiguo (¡qué!). Cuando estábamos configurando nuestro entorno de compilación automatizada hace unos años, descubrimos que MSBuild.exe no manejaba correctamente todas las dependencias que tenemos.

Trabajando con Microsoft pudimos resolver algunos de los problemas pero no todos. Si mi memoria me sirve, nunca podríamos obtener los ensamblados de C # que dependían de las dll de C ++ administradas para construir. Así que terminamos haciendo una secuencia de comandos de compilación personalizada que llamaba devenv.exe desde la línea de comandos y funcionó bien.

Por supuesto, eso fue con VS2005, podría estar arreglado ahora, pero la secuencia de comandos aún funciona, por lo que no hemos revisado el problema.