Diferencias entre Visual Studio (.sln) construir corredor y MSBuild

Question

Estoy tratando de establecer TeamCity hacer un IC usando .Net y configuración de construir corredores que tienen:

1. Visual Studio (SLN)
2. MSBuild
3. Visual Studio 2003

Cuál es la diferencia? ¿Por qué tres compilación para trabajar en el mismo tipo de proyecto? (? Con la excepción de 2003, que es sólo para el año 2003 creo, por qué)

Tomando el tema, tenemos esta construcción corredores de archivos .exe:

1. .NET Proceso Runner
2. línea de comandos

El corredor de compilación "Command Line" no funciona con ningún ensamblado .net? ¿Por qué el .Net Process Runner?

Answer 1

Visual Studio (SLN)
Si su solución es pequeña y que no están obligados a hacer cosas de lujo puede utilizar Visual Studio (SLN) construir corredor. Hace exactamente lo mismo que cuando se ejecuta Project-> Build (del menú VS). Esta opción es muy fácil de configurar, unos pocos clics y su servidor CI compila su solución.

MSBuild
Si lo que necesita hacer más escenarios avanzados, aparte de la simple recopilación, como aplicar diferentes archivos de configuración, insertar valores transformados en el archivo de configuración, despliegue binarios, etc, se selecciona la opción de MSBuild. Sabrá cuándo necesita usar esto, simplemente porque el creador de sln no podrá hacer nada. Esta opción requiere cierto conocimiento del lenguaje de creación de secuencias de comandos, que se basa en tareas y tiene un estilo xml.

Answer 2

Si usa los archivos de la solución (Visual Studio), esto significa que necesita licenciar una copia de Visual Studio para su servidor de compilación junto con la instalación/mantenimiento que viene con eso. Si usa MSBuild no necesita nada de eso, todo lo que necesita son las instalaciones de .net framework. La única diferencia real entre los dos es que Visual Studio tiene todo tipo de variables de entorno establecidas y utiliza cosas como el orden de compilación. Si bien MSBuild no tiene variables de entorno establecidas de manera predeterminada, y no reconoce el orden de compilación, solo reconfigura las dependencias. Sin embargo, será un poco más fácil en Visual Studio y no se encontrará con esos casos de forma ocasional en los que estuvo dependiendo de Visual Studio para cubrir algunos descuidos.

Answer 3

Cuando usa MSBuild para compilar un archivo .SLN (documento que no es MSBuild) genera un archivo MSBuild en memoria que hace referencia a todos los proyectos para compilar en la configuración especificada y luego lo ejecuta. Cuando utiliza Visual Studio para compilar, en su lugar está llamando a DevEnv.com.

Existen ciertos tipos de proyectos (C++ en 2005/2008 y VDPROJ en 2005/2008/2010) que no son archivos MSBuild y no pueden compilarse utilizando solo MSBuild. Obtendrá una advertencia de compilación diciendo que uno o más proyectos no eran proyectos válidos de MSBuild y no se pudieron construir.

In geneneral trato de mantener las máquinas de construcción magras y malas y solo instalar Visual Studio si es necesario.

Answer 4

He notado muy poco entre los dos. Específicamente en nuestra instancia, necesitábamos construir un .vdproj. Ahora, después de buscar en Google hay dos corredores para hacer esto, el corredor de línea de comando o el Visual Studio (sln). Sin embargo, al ejecutar el tipo de corredor de Visual Studio (sln) obtenemos el siguiente error: "[Advertencia] C: \ BuildAgent \ work \ 1bd75058d7bca32b \ POS \ PoSWidgetInstaller \ myInstaller.vdproj.metaproj warning MSB4078: El archivo de proyecto" myInstaller \ myInstaller .vdproj "no es compatible con MSBuild y no se puede construir".

Y no falla cuando se construye en la solución. Creo que el tipo de corredor de Visual Studio (sln) extrae los datos del archivo sln y luego los usa con MSbuild. No estoy seguro no puedo confirmarlo, solo mis pensamientos al respecto.