ASP.NET MVC en IIS 6

Desde hace unos días estuve intentando hacer andar ASP.NET MVC sobre IIS 6, hay un problema documentado por el cual nos encontramos con el error “The Page cannot be found” cuando queremos acceder a una determinada View

Luego de recorrer y probar varias soluciones de lo mas diversas que iban desde modificar el código fuente de mi aplicación a configurar el IIS me quedé con esta que les cuento a continuación.

Pasos para hacer funcionar ASP.NET MVC sobre IIS 6

1. En las propiedades del sitio (o el directorio virtual) vamos a la sección “Application settings” y entramos en “Configuration”

2. en “Wildcard application maps” vamos a “Insert” y agregamos “c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll” (o “Edit” en caso de que exista)

3. y ATENCIÓN a que NO esté tildada la opción “Verify that file exists”

Finalmente aceptamos todas las ventanas que fuimos abriendo y el sitio debería estar funcionando.

referencias: http://www.google.com.ar/search?q=asp.net+mvc+on+iis+6

Integración Continua (CI)

Pensando la integración continua

La integración continua consiste en verificar que todo sigan funcionando mediante la compilación y ejecución de test en forma desatendida. es una práctica altamente recomendada cuando se trabaja en equipos de desarrollo y sobre todo muy positiva cuando los equipos son distribuidos.

También se extiende a la generación desatendida de builds, deploy a QA, métricas como puede ser el coverage, etc.

Armando una integración continua

En este caso vamos a usar:

• CruiseControl.NET como servidor de integración continua.
• MSBuild y MSBuild.Community.Tasks para automatizar tareas.
• PartCover para medir coverage.

No voy a hacer un step by step de como configurar cada una pues depende de las variantes que se quieran instalar en cada caso particular, pero cualquier duda concreta podés dejar un mensaje y la vemos.

Armando proyectos en Cruise Control

primero vamos a definir nuestro proyecto:

<project name="dms.ci" queue="dms">

donde name es el nombre por el que nos vamos a referir a este proyecto, queue es la cola de trabajo en la que participa el proyecto, esto sirve para agrupar los proyectos que NO se quieren ejecutar simultáneamente.

cada proyecto se dividen en cuatro partes principales:

1. triggers: definición de cuando vamos a disparar las tareas y ante que condiciones

En este caso estamos actualizando el proyecto cada 5 minutos y si hay novedades ejecutamos las tareas.

<triggers>
    <intervalTrigger seconds="3600" initialSeconds="1" />
</triggers>

O el famoso Nightly build, que en este caso se ejecuta de lunes a viernes a las 4 am.

<triggers>
    <scheduleTrigger time="4:00">
        <weekDays>
            <weekDay>Monday</weekDay>
            <weekDay>Tuesday</weekDay>
            <weekDay>Wednesday</weekDay>
            <weekDay>Thursday</weekDay>
            <weekDay>Friday</weekDay>
        </weekDays>
    </scheduleTrigger>
</triggers>

2. sourcecontrol: obtención de las novedades del código fuente

En este caso las obtenemos desde el repositorio svn de google code.

<sourcecontrol type="svn">
    <trunkUrl>https://dmsneluz.googlecode.com/svn/trunk</trunkUrl>
    <workingDirectory>c:\cruisecontrol\dms\CI</workingDirectory>
</sourcecontrol>

3. tasks: tareas a ejecutar

En este caso se trata de una tarea de MSBuild escrita en el archivo src/dms.msbuild cuyo target es Testing. (ver: lista (in)completa de tareas)

<tasks>
    <msbuild>
        <executable>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
        <workingDirectory>c:\cruisecontrol\dms\CI</workingDirectory>
        <projectFile>src\dms.msbuild</projectFile>
        <buildArgs>/noconsolelogger</buildArgs>
        <targets>Testing</targets>
        <timeout>900</timeout>
        <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
    </msbuild>
</tasks>

4. publishers: informar los resultados

En este caso estamos agregando al reporte del CruiseControl el contenido de Reports\nunit-test.xml que es donde tenemos el resultado de la ejecución de los test que posteriormente va a ser vizualizado en el dashboard de ccnet.

<publishers>
    <merge>
        <files>
            <file>c:\cruisecontrol\dms\CI\Reports\nunit-test.xml</file>
        </files>
    </merge>

    <xmllogger />
</publishers>

Dashboard del proyecto de ejemplo

hay una copia de los archivos de configuración actuales de cc en el repositorio del ejemplo, en la carpeta ccnet.

Post relacionado: Coverage con PartCover en un servidor de CI