version control - studio - MSBuild: ¿usa el archivo.csproj o hace el suyo propio?

project json vs csproj (7)

OK, así que concedo fácilmente que soy un novato en lo que respecta a la integración continua.

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

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

Están sucediendo muchas cosas aquí que no estoy seguro de que realmente necesite en un entorno de construcción automatizado.
No creé este archivo. No lo entiendo, y eso me asusta. ( Programación por coincidencia )
La mayor parte de lo que está sucediendo parece $(MSBuildToolsPath)/Microsoft.CSharp.targets abstraído a través de $(MSBuildToolsPath)/Microsoft.CSharp.targets
Como resultado de 1, 2 y 3, la modificación del archivo para incluir algo como MbUnit parece intrincado y más difícil de lo que debe ser. Mi única opción real es incluirlo en la sección AfterBuild , que parece algo así como un truco para mí.

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

Al usar MSBuild, ¿es aconsejable usar el archivo .csproj generado por VS como el archivo de compilación? ¿O debería crear el mío?
¿Las pruebas de MbUnit deberían ser 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?
Similar a la pregunta 2. Si agrego las pruebas de MbUnit al archivo MSBuild y termino usando el archivo .csproj, ¿el Target Name="AfterBuild" realmente la sección para agregar esa información? ¿No debería haber una sección Target Name="Test" ? El uso del archivo .csproj generado por VS parece evitar la segunda opción.

Sé que hay muchas cosas 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 esté equivocado, la curva de aprendizaje para este tema no es No es una curva en absoluto, es una función de paso. :)

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

Deje el archivo csproj bien solo (como dices, no lo entiendes).

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. Dile a tu servidor de CI que construya tu archivo de compilación.

Esta separación hace que sea más fácil agregar sus propias tareas previas y posteriores (pruebas unitarias, pruebas de humo de scripts SQL, fxcop / otro análisis estático, etc.) y no romperá su entorno de trabajo. También significa que puede hacer sus objetivos personalizados en lo que desee (msbuild / ant, etc.). Mire como MSBuildContrib en codeplex para mayor bondad.

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

OK, algunas cosas de las que hay que estar pendiente. El formato csproj ha cambiado de VS2005 a VS2008. Además, si va con MSBuild, recuerde que no podrá construir archivos .vdproj (setup); para eso necesitas devenv (el ejecutable VS). Dicho esto, siempre puedes crear una tarea MSBuild que invoque devenv y la cree para ti.

En cuanto a su pregunta sobre si crear su propio archivo csproj o usar el creado por VS2005, sugeriría un camino intermedio: cree su propia plantilla de proyecto , que atienda sus necesidades y deje que VS se encargue del resto.

Personalmente creo que está bien ir con el archivo .csproj. No está sucediendo mucho allí que no tendría que agregarse a sí mismo si desarrolla su propio proyecto MSBuild.

Sin embargo, cualquiera que sea la ruta que decida utilizar, le recomiendo que no agregue el MbUnit como parte de su paso de compilación, sino que lo agregue como un paso separado en CC.Net. Las pruebas unitarias en ejecución deben ser parte del ciclo diario de IC; sin embargo, no debería ser parte de cada construcción.

Cree su propio archivo de proyecto (todo lo que termine con * proj sea considerado un archivo de proyecto por MSBuild) y llame a su compilación desde allí. Me gusta esto:

<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, que generalmente es más fácil que tener un montón de archivos csproj ...

Está bien usar .csproj como entrada para msbuild. Puede agregar tareas manualmente en csproj, que se ignorarán al realizar un pedido desde VS. Pero si va a hacer algunas cosas no triviales, es mejor crear scripts separados de msbuild. Y pueden ser referenciados desde archivos csproj. ¿Has echado un vistazo al MS Build Server que es parte de TFS? Se integra con SourceControl de TFS y podría usarse para CI. Sus archivos de proyecto son scripts de msbuild.

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

Yo uso NAnt y MSBuild. NAnt se actualizó con NAntContrib para que obtuviera las tomas de msbuild. Puedo ser una configuración temporal, pero hasta ahora no he tenido problemas importantes. Dicho esto, tampoco creo un nuevo archivo csproj porque utilizo el mismo csproj / sln que uso en VS2008. La construcción de proyectos con msbuild simplificó en gran medida las secuencias de comandos de NAnt (utilizamos la tarea de csc ).

Notas:

Si utiliza Windows Workflow Foundation en sus proyectos, tendrá grandes dificultades para construir dicho proyecto sin msbuild.
No instales VS.NET en tu máquina de compilación. Puede usar Wix do create installation msi.
@Franci Penov: las pruebas de unidades en ejecución DEBERÍAN formar parte de cada construcción. ¿De verdad quieres esperar hasta mañana para encontrar un error? Hay una nota al margen: las pruebas unitarias deben ejecutarse muy rápido.

Yo recomendaría usar los archivos .csproj generados, de hecho para producción, creo que usar los archivos .sln generados es una buena idea. Descubrí que ganarás utilizando los mismos archivos de solución que los desarrolladores.

Tenga en cuenta que los archivos .sln no son realmente archivos de proyecto de msbuild válidos, sino que se transforman en proyectos msbuild por sí mismo cuando se usan como entradas. ¡Difícil!

Para fines de aprendizaje, es posible que desee registrar la compilación de un .csproj y dar un paso adelante para tener una idea de lo que está sucediendo. 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 continuo con tareas de msbuild para construir sus proyectos y ejecutar sus pruebas unitarias. De esta manera, los desarrolladores no tienen que ejecutar la prueba unitaria cada vez que compilan, pero cada vez que integran su código se ejecutarán las pruebas unitarias. Y sí, ¡asegúrese de que corran rápido! Todo lo que tome más de un segundo se debe ejecutar durante una compilación programada (¿nocturna?). Probablemente sean menos pruebas unitarias y más pruebas de integración escritas con un marco de prueba unitaria si tardan más de un segundo.

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