.net - una - Diferencias entre Visual Studio(.sln) build runner y MSBuild

proyectos hechos en visual basic 2010

Question

Estoy tratando de configurar TeamCity para que realice un CI usando .Net y configurando los corredores de compilación que tengo:

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

¿Cual es la diferencia? ¿Por qué tres construyen para trabajar en el mismo tipo de proyecto? (Con la excepción de 2003, que es solo para 2003, creo, ¿por qué?)

Tomando el problema, tenemos esta compilación de corredores para archivos .exe:

1. .NET Process Runner
2. Línea de comando

¿El corredor de compilación "Línea de comando" no funciona con ningún ensamblaje .net? ¿Por qué el .Net Process Runner?

Answer 1

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

Hay ciertos tipos de proyectos (C ++ en 2005/2008 y VDPROJ en 2005/2008/2010) que no son archivos de MSBuild y no se pueden compilar con solo MSBuild. Recibirá una advertencia de compilación que indica que uno o más proyectos no eran proyectos de MSBuild válidos y no se pudieron compilar.

En general, trato de mantener máquinas de construcción lean y mean y solo instalo Visual Studio si es necesario.

Answer 2

He notado muy poco entre los dos. Específicamente en nuestra instancia necesitamos construir un .vdproj. Ahora, después de googlear allí, hay dos corredores para hacer esto, el corredor de línea de comandos o Visual Studio (sln). Sin embargo, al hacer el tipo de corredor de Visual Studio (sln) obtuvimos el siguiente error: "[Warning] C: / BuildAgent / work / 1bd75058d7bca32b / POS / PoSWidgetInstaller / myInstaller.vdproj.metaproj warning MSB4078: El archivo de proyecto" myInstaller / myInstaller / myInstaller. vdproj "no es compatible con MSBuild y no se puede compilar".

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

Answer 3

Si usa los archivos de la solución (Visual Studio) de manera que tenga que 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 ninguna variable de entorno establecida de forma predeterminada y no reconoce el orden de compilación, solo reconoce las dependencias. Aunque será un poco más fácil en Visual Studio y no se encontrará con esos casos ocasionalmente en los que dependía de Visual Studio para cubrir un poco de descuido.

Answer 4

Visual Studio (sln)
Si su solución es pequeña y no está obligado a hacer cosas sofisticadas , puede usar Visual Studio (sln) build runner. Hace exactamente lo mismo que cuando haces Proyecto-> Construir (desde el menú VS). Esta opción es muy fácil de configurar, unos pocos clics y su servidor de CI compila su solución.

MSBuild
Si necesita realizar escenarios más avanzados , además de compilar de manera simple, como aplicar diferentes archivos de configuración, insertar valores transformados en el archivo de configuración, implementar binarios, etc., debe seleccionar la opción MSBuild. Sabrás cuándo necesitas usar esto, simplemente porque sln builder no será capaz de hacer cosas. Esta opción requiere cierto conocimiento del lenguaje de creación de scripts, que es un tipo xml y basado en tareas.