.NET at the train

Build problems after upgrading from TFS2010 to TFS2012

Raúl Alarcón — Wed, 10 Apr 2013 07:47:00 GMT

Recently our TFS Server have been upgraded to TFS2012 + QU1 + CU1. In order to be able to use our Build Server we have had to upgrade it from TFS2010 to TFS2012 as well and, of course, we have found a couple issues related to the build process templates...(read more)

SSIS, SQL Agent, Credential, Proxies and the -1073741515 process exit code

Raúl Alarcón — Wed, 27 Feb 2013 09:55:00 GMT

Recently I have been dealing with a really weird error while trying to execute a SSIS package using a SQL Agent Job with a concrete user credential. The error that I've got was: Executed as user: XXXXX. The step did not generate any output. The return...(read more)

Useful T-SQL Scripts

Raúl Alarcón — Mon, 28 Jan 2013 08:08:00 GMT

A couple of very useful and heavy used T-SQL scripts... Finally, I have decided to post both in order to find them every time I need with out having to re-author: 1. Kill all existing connections to a certain database: USE master DECLARE @DataBaseName...(read more)

Error 1603 installing AppFabric 1.1 for Windows Server

Raúl Alarcón — Wed, 17 Oct 2012 21:31:00 GMT

I been dealing for some time with an error installing AppFabric 1.1. for Windows Server. All started when, after having AppFabric installed my laptop runs in a System Restore after having updated the video driver. The restore puts my system in a previous...(read more)

Web App Performance Counters Compilation

Raúl Alarcón — Wed, 03 Oct 2012 05:54:00 GMT

In order measure the performance of a common web application (a web frontend connected to a database server), to which performance counters we have to pay attention?. If we are trying to diagnose a performance problem, where to start?. What does each...(read more)

IP Lockdown en Web Roles de Azure

Raúl Alarcón — Tue, 05 Jun 2012 15:43:29 GMT

En el proyecto actual hemos tenido la necesidad de limitar el acceso los Web Roles de manera que sólo determinadas IPs pueden alcanzar el sitio web público. Básicamente se trata de limitar la superficie de exposición de la aplicación ya que el objetivo...(read more)

Índices grandes en SQL Azure, error 40552

Raúl Alarcón — Wed, 07 Mar 2012 22:50:47 GMT

El otro día, en el proyecto donde estoy trabajando ahora, me encontré con la siguiente situación: en una base de datos SQL Azure, sobre una tabla que tenía más de 10 millones de registros, necesito crear un índice para optimizar una serie de consultas. La tabla, contiene cerca de 100 campos y en el índice quiero incluir un número importante de ellos (unos 25).

El resultado inicial, después de 15 minutos, es el siguiente:

Msg 40552, Level 20, State 1, Line 1
The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.

El problema lo entiendo perfectamente: estoy consumiendo mucho log de transacciones por que la tabla tiene muchas filas y estoy creando un índice bastante grande, pero… ¿¡QUE HAGO!?, yo necesito ese índice. Estos errores se enmarcan dentro de los errores de transitorios SQL Azure (en concreto de pérdida de conexión).

Bien, dando una vuelta por la documentación de los errores (muy buena por cierto) veo que menciona que a la hora de reconstruir un índice puedes utilizar la opción “WITH (ONLINE=ON)”. Pues no sólo vale para “reconstruir”, también vale para crear nuevos índices o borrar existentes.

Ale, problema resuelto.

Configuración Avanzada (y flexible) en Windows Azure

Raúl Alarcón — Wed, 29 Feb 2012 22:58:00 GMT

Entre @ridomin y yo hemos escrito un artículo sobre la configuración de aplicaciones en Windows Azure considerando todo el ciclo de vida de las aplicaciones y los requisitos que un proceso de construcción de software formal tiene.

Podéis leer la versión en castellano aquí en mi blog y la versión en inglés en el blog de Rido.

Este artículo es el primero de una serie en la que esperamos ir construyendo una herramienta para gestionar de forma avanzada, y desde un punto de vista novedoso, la configuración de las aplicaciones que se ejecutan en Azure. Hemos escrito el articulo de los conceptos más globales a los más concretos, planteando un concepto de solución de la cual ya tenemos una PoC.

Espero que os guste.

Windows Azure y Classic Pipeline (Segunda Parte)

Raúl Alarcón — Mon, 19 Dec 2011 22:27:15 GMT

En la primera parte, vimos los requisitos que teníamos que cumplir para poder ejecutar una aplicación web diseñada para IIS 6.0 en un IIS 7.0 ó 7.5, y por ende, para poderla ejecutar en Windows Azure. El principal requisito es que la aplicación pueda utilizar el Modo Clásico del pipeline de .NET.

El único inconveniente de la solución aportada en la primera parte es que sólo es apta para aplicación que utilicen la versión de .NET 2.0/3.5.

Al ejecutar una aplicación en .NET 4.0 y que además utilice el pipeline clásico, nos encontraremos con un error 404 (File or directory not found), que la verdad, nos puede dejar un poco descolocados:

Como casi no nos lo podemos creer, nos vamos al servidor y vemos que el error tiene un pequeño matiz, el error es un 404.2:

Vemos que el problema está relacionado con el ISAPI que maneja las peticiones ASPX. Buscando literatura vemos que la raíz del problema es que, por defecto, el filtro ISAPI para .NET 4.0 no está activado por defecto. Podemos verlo en la siguiente imagen:

Bueno, una vez diagnosticado el problema sólo tenemos que buscar la manera de poder habilitar el filtro ISAPI para .NET 4.0 de manera automática (cómo ya explicamos en la primera parte, al tratarse de Azure no podemos realizar las configuraciones manualmente).

Buscando buscando, encontré la manera de modificar la sección de configuración de IIS que gestiona los filtros ISAPI (<isapiFilters>) y preparé un nuevo método dentro de nuestra clase RoleEntryPoint para establecer la configuración necesaria, el método AllowAspNet4Isapi:

     Private Sub AllowAspNet4Isapi()

        Trace.WriteLine("AllowAspNet4ISAPI...")

        Dim serverManager As ServerManager = New ServerManager

        Try

            Dim config As Configuration = ServerManager.GetApplicationHostConfiguration

            Dim isapiCgiRestrictionSection As ConfigurationSection = config.GetSection("system.webServer/security/isapiCgiRestriction")

            Dim isapiCgiRestrictionCollection As ConfigurationElementCollection = isapiCgiRestrictionSection.GetCollection

            Dim elems = isapiCgiRestrictionCollection.Where(Function(ce) ce.Attributes("description").Value = "ASP.NET v4.0.30319")

            For Each e As ConfigurationElement In elems

                Trace.WriteLine("Accessing to set 'allowed'=true...")

                e.Attributes("allowed").Value = True

            Next

            serverManager.CommitChanges()

        Catch ex As Exception

            Trace.WriteLine("Se ha producido un error: " + ex.Message)

            Trace.WriteLine("Exception: " + ex.ToString())

        Finally

            serverManager.Dispose()

        End Try

    End Sub

Con este nuevo método y un pequeño refactoring, OnStart() queda como sigue:

    Public Overrides Function OnStart() As Boolean

        'Configure Azure Tracing

        ConfigureTracing()

        'Permitir el ISAPI de .NET 4.0

        AllowAspNet4Isapi()

        'Configure Azure Pipeline

        SetClassicIISPipelineMode()

        Return MyBase.OnStart()

    End Function

Espero que os sea de utilidad, aunque repitiendo lo ya dicho en la primera parte, mi recomendación personal es actualizar la aplicación para poder ejecutarla utilizando el modo integrado, que tiene bastantes ventajas sobre el clásico (ref1, ref2).

Windows Azure y Classic Pipeline

Raúl Alarcón — Wed, 16 Nov 2011 22:32:39 GMT

Por defecto, Windows Azure únicamente puede ejecutar aplicaciones web sobre IIS7.5, o por decirlo de otra manera, aplicaciones que utilizan el pipeline de IIS en modo integrado.

Aunque mi recomendación personal es actualizar la aplicación para poder ejecutarla utilizando el modo integrado, este post propone una alternativa para poder ejecutar una aplicación que necesite el pipeline en modo clásico, aunque sea como solución a corto plazo. Una buena referencia sobre como migrar aplicaciones de IIS 6.0 a IIS 7.0 está disponible aquí.

Para poder ejecutar una aplicación web diseñada para IIS 6.0 en un IIS 7.0 ó 7.5 simplemente tenemos que asegurarnos de que el Application Pool que utiliza esté configurado con un pipeline en modo clásico. Un equipo con Windows 7 o Windows 2008 R2 y con el .NET Framework 4.0 instalado tendrá los siguientes application pools por defecto:

El error “Request is not available in this context” es uno de los más comunes que se reciben si una aplicación web desarrollada para utilizar el pipeline en modo clásico se ejecuta en modo integrado:

Como hemos dicho, para que una aplicación web pueda ejecutarse con un pipeline en modo clásico sólo tenemos que modificar su application pool:

Bien, el problema que se nos presenta en Windows Azure es que, si queremos que nuestro cambio sea persistente y coherente con el modelo de Azure, no podemos modificar la configuración manualmente ya que en el caso de que nuestro servidor(es) se regenerara, perderíamos dicha configuración.

La única alternativa que tenemos es utilizar la infraestructura software de Windows Azure, concretamente la clase RoleEntryPoint. Para ello, añadimos una clase en nuestra aplicación web que herede de RoleEntryPoint, después sobre-escribiremos el método “OnStart()” con el siguiente código (esta vez Visual Basic .NET):

     Public Overrides Function OnStart() As Boolean

        Dim srvManager As New ServerManager()

        Try

            Dim appSite = (From site In srvManager.Sites

                          Where site.Name.Contains(RoleEnvironment.CurrentRoleInstance.Role.Name)).FirstOrDefault()

            If Not appSite Is Nothing Then

                Dim appPool = (From pool In srvManager.ApplicationPools

                          Where pool.Name = appSite.Applications(0).ApplicationPoolName).FirstOrDefault()

                If (Not appPool Is Nothing) Then

                    appPool.ManagedPipelineMode = ManagedPipelineMode.Classic

                    srvManager.CommitChanges()

                End If

            Else

                Trace.WriteLine("Unable to get AppSite reference")

            End If

        Catch ex As Exception

            Trace.WriteLine("Exception: " + ex.ToString())

        Finally

            srvManager.Dispose()

        End Try

    End Sub

Este código depende de la librería Microsoft.Web.Administration por lo que tendrás que añadir la referencia en el proyecto.

La siguiente vez que ejecutemos la aplicación en un contexto Azure (tanto en el emulador como en un entorno Windows Azure real), el pipeline se configurará automáticamente para utilizar el modo clásico. Si el Web Role se regenera, no hay problema, el método “OnStart()” será invocado de nuevo.

Por último decir que este método sólo es válido si la aplicación utiliza .NET Framework 2.0/3.5. Para poder ejecutar una aplicación .NET Framework 4.0 en modo clásico hay que pasar por algún que otro inconveniente más y añadir más configuración (lo sé, no es algo que tenga mucho sentido, lo mejor sería actualizarla, pero hay de todo en la viña del Señor)… pero eso lo veremos en el siguiente post!