MSBuild - ¿Usar el archivo .csproj o rodar el tuyo?

Question

Está bien, por lo que admito que soy un novato en lo que respecta a la integración continua.

Dicho esto, estoy intentando configurar un entorno de CC.NET para educarme, pero tengo problemas para encontrar la información que necesito para configurar la parte de compilación automatizada.

Tal como lo entiendo, en C #, el archivo .csproj producido por VS 2005 y reenviar es un archivo MSBuild válido. A saber, he podido integrar la tarea de MSBuild en CC.NET usando el archivo .csproj, pero tengo algunos problemas con esto:

1. Aquí hay muchas cosas que no estoy seguro de necesitar en un entorno de compilación automatizado.
2. No he creado este archivo. No lo entiendo, y eso me asusta. ( Programación por coincidencia )
3. La mayoría de lo que está sucediendo parece estar abstraído a través de $(MSBuildToolsPath )\Microsoft.CSharp.targets
4. Como resultado de 1, 2 y 3, la modificación del archivo para incluir algo como MbUnit parece complicada y más difícil de lo que debe ser. Mi única opción real es incluirlo en la sección AfterBuild , que me parece un truco.

Entonces, algunas preguntas para la gente de CC.NET, la gente de MSBuild y la gente de MbUnit.

1. Al usar MSBuild, ¿es recomendable usar el archivo .csproj generado por VS como el archivo de compilación? ¿O debería crear mi propio?
2. ¿Deben las pruebas de MbUnit formar parte del archivo MSBuild o del archivo CC.NET? Mi investigación parece sugerir que pertenecen al archivo MSBuild. Si ese es el caso, ¿creo un nuevo archivo .proj de MSBuild y lo compruebo en CVS además del archivo .csproj? ¿O la tarea MbUnit se convierte en parte de mi archivo .csproj?
3. Similar a la pregunta 2. Si agrego las pruebas de MbUnit al archivo MSBuild y termino usando el archivo .csproj, es el Target Name = " AfterBuild " realmente la sección para agregar esa información ? ¿No debería haber una sección Target Name = " Prueba " ? El uso del archivo .csproj generado por VS parece impedir la segunda opción.

Sé que hay mucho allí, pero la mayoría de lo que he podido encontrar en línea asume un cierto nivel de familiaridad con estos temas que simplemente no tengo, a menos que me equivoque, la curva de aprendizaje para esto no es una curva, es una función escalonada. :)

Edición 1: actualicé el texto para que sea un poco más conciso y para abordar algunas preguntas persistentes que he tenido con las respuestas.

Answer 1

Recomendaría usar los archivos .csproj generados. De hecho, para la producción, creo que usar los archivos .sln generados es una buena idea. Descubrí que ganará utilizando los mismos archivos de soluciones que los desarrolladores.

Tenga en cuenta que los archivos .sln no son en realidad archivos de proyecto msbuild válidos, ya que msbuild los transforma en proyectos msbuild cuando se utilizan como entradas. ¡Difícil!

Para fines de aprendizaje, es posible que desee registrar la creación de un archivo .csproj y avanzar para tener una idea de lo que está sucediendo. Sin embargo, MSBuild es un poco más declarativo que nant, así que tómate tu tiempo y experimenta un poco.

Finalmente, envolvería sus archivos .sln o .csproj en un proyecto de script de compilación continua con tareas de msbuild para construir sus proyectos y ejecutar sus pruebas unitarias. De esta manera, los desarrolladores no tienen que ejecutar la prueba de unidad cada vez que construyen, sino que cada vez que integran su código, las pruebas de unidad se ejecutarán. Y sí, ¡asegúrate de que corren rápido! Cualquier cosa que tome más de un segundo debe ejecutarse durante una compilación programada (¿por la noche?) En su lugar. Es probable que sean menos pruebas de unidad y más pruebas de integración escritas con un marco de prueba de unidad si toman más de un segundo.

Editar: alguna información adicional que he encontrado útil: el uso de MSBuild 3.5 le permitirá obtener el resultado de destino de un archivo .sln, mientras que esta información no se devuelve en MSBuild 2.0 (aunque creo que debería funcionar para archivos .csproj en ambas versiones). Puede usar la salida (sus archivos construidos) como entradas para el marco de prueba de su unidad.

Answer 2

Deje el archivo csproj solo (como usted dice, no lo entiende)

Cree su propio archivo de proyecto msbuild y llame al csproj (o sln) desde su archivo de compilación principal a través de la tarea msbuild. Dígale a su servidor de CI para construir su archivo de compilación.

Esta separación hace que sea más fácil agregar sus propias tareas previas y posteriores (pruebas de unidad, scripts SQL de prueba de humo, análisis fxcop / otros, etc.) y no romperá su entorno de trabajo. También significa que puedes hacer tus objetivos personalizados en cualquier cosa que desees (msbuild / ant, etc.) Echa un vistazo a MSBuildContrib en codeplex para una bondad adicional.

No necesita un stuido visual en su servidor de compilación (a menos que tenga proyectos de implementación, a menos que esto también haya cambiado desde la última vez que lo busqué)

Answer 3

Crea tu propio archivo de proyecto (cualquier cosa que termine con * proj es considerado un archivo de proyecto por MSBuild) y llama a tu compilación desde allí. Así:

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

Tenga en cuenta que msbuild también puede compilar .sln (archivo de solución) sin ningún cambio, lo que suele ser más fácil que tener un montón de archivos csproj ...

Answer 4

Utilizo tanto NAnt como MSBuild. NAnt se actualizó con NAntContrib para obtener msbuild taks. Puede que tenga una configuración temporal, pero hasta ahora no he tenido problemas importantes. Dicho esto, tampoco creo un nuevo archivo csproj porque uso el mismo csproj / sln que uso en VS2008. Construyendo proyectos con msbuild scripts NAnt heredados enormemente simplificados (usamos csc tarea).

Notas:

1. Si usa Windows Workflow Fundación en tus proyectos lo harás. tienen grandes dificultades para construir tales Proyecto sin msbuild.
2. No instale VS.NET en su máquina de compilación. Puede usar Wix para crear la instalación de msi.
3. @Franci Penov: las pruebas de unidades en ejecución DEBERÍAN ser parte de cada compilación. ¿Realmente quieres esperar hasta mañana para encontrar un error? Hay una nota al margen: las pruebas unitarias deben ejecutarse muy rápido.

Answer 5

Personalmente creo que está bien ir con el archivo .csproj. No hay mucho que hacer allí que no tendrías que agregarte si haces tu propio proyecto de MSBuild.

Sin embargo, sea cual sea la ruta a la que decida ir, todavía recomiendo no agregar la MbUnit como parte de su paso de compilación, sino agregarla como un paso separado en CC.Net. Las pruebas unitarias de ejecución deben formar parte del ciclo diario de IC; sin embargo, no debería ser parte de cada compilación.

Answer 6

Está bien, hay algunas cosas a tener en cuenta. El formato csproj ha cambiado de VS2005 a VS2008. Además, si va con MSBuild, recuerde que no podrá compilar archivos .vdproj (configuración); para eso necesitas devenv (el ejecutable de VS). Dicho esto, siempre puedes crear una tarea de MSBuild que llame a devenv y la compile por ti.

En cuanto a su pregunta sobre si construir su propio archivo csproj o usar el creado por VS2005, sugeriría un camino intermedio: crea tu propia plantilla de proyecto , que se adapta a tus necesidades y permite que VS se encargue del resto.

Answer 7

Está bien usar .csproj como entrada para msbuild. Puede agregar tareas manualmente para él en csproj que se ignorarán durante el proceso de cumplimiento de VS. Pero si vas a hacer algunas cosas no triviales, es mejor crear scripts de msbuild separados. Y pueden ser referenciados desde archivos csproj. ¿Echó un vistazo a MS Build Server, que forma parte de TFS? Se integra con SourceControl de TFS y podría utilizarse para CI. Sus archivos de proyecto son msbuild scripts.

  

Si usé nAnt, ¿es necesario que VS esté instalado en el servidor?   ¿Quiso decir 'MSBuild'? No, no es necesario instalar VS para usar msbuild con archivos csproj.