Pequeño apunte para que no se me olvide.
Microsoft publicó hace un tiempo un proveedor / componente para permitir que
productos que no soportan de forma nativa la conexión con el control de
versiones de TFS puedan soportarlo.
Según la documentación de aquí,
este proveedor permite conectar a TFS 2010 desde, entre otros, Visual
Studio .NET 2003, Visual Visual Basic 6 SP6 y
SQL Server Management Studio.
Mi experiencia personal ha sido con VS.NET 2003 y funciona 'de lujo' así que
entiendo que con el resto de productos funcionará también perfectamente.
¡Ojo! Requiere .NET 4.0 y Team Explorer 2010 para funcionar.
El proveedor está disponible para su descarga en el enlace anterior.
miércoles, 21 de septiembre de 2011
viernes, 9 de septiembre de 2011
Excepción BadImageFormatException en IIS 7.5
Ayer tuvimos algún 'pequeño' problema al generar un entorno de prueba de una
aplicación web ASP.NET. La situación más o menos vino a ser la siguiente:
Problema:
Al acceder a la dirección web de la aplicación, se produce una excepción de ASP.NET del tipo BadImageFormat.
Solución (¿solución?):
Fácil (yujuu!) El equipo en el que la aplicación está instalada es un Windows 7 en 64 bits, con lo que si está dando esa excepción, el sospechoso más habitual indica que el proyecto en Visual Studio está compilado en 32 bits, así que para solucionar el problema, basta con acceder a las propiedades del proyecto y especificar que la compilación sea compatible con 'Any CPU', tal y como vemos en la siguiente captura (Como el proyecto es en VB.Net, la captura corresponde a las propiedades de un proyecto en ese lenguaje)
Listo. Cambiamos la opción de compilación, compilamos la solución y la instalamos, y a funcionar… un momento, ¿no funciona?
Problema 2:
Al acceder a la aplicación ya compilada correctamente, aparece una nueva excepción. Esta excepción, de la que no tengo captura, decía que no podía cargarse en memoria uno de los ensamblados referenciados por la aplicación (en concreto se trata de un ensamblado Interop) toca 'bucear' un poco en la excepción y darle un poco al 'coco'… Vale, ya lo tenemos!!!
Solución 2:
La segunda excepción está directamente relacionada con la primera, ya que al compilar la aplicación para 'Any CPU' hemos conseguido que la aplicación arranque correctamente en IIS (64 bits) peeero cuando esa aplicación realiza una instancia del componente Interop (compilado en 32 bits) resulta que no puede crear los objetos porque no son compatibles. Menos mal que IIS 7.5 tiene la opción de permitir aplicaciones en 32 bits… ¿dónde?
Vamos al listado de los Application Pools, y en el Pool asociado a la aplicación vamos a las opciones avanzadas:
Aceptamos el cambio, IISReset por si acaso, y a volar!!!!
Explicaciones:
El primer error como he comentado estaba provocado por el tipo de compilación del proyecto. Al compilarlo en 32 bits, los procesos de IIS que se ejecutan en 64 bits no eran capaces de arrancar la aplicación, con lo que cambiamos el modo de compilación a 'Any CPU' para que el compilado sea capaz de adaptarse tanto a 64 como a 32 bits (opción recomendada)
El segundo error estaba provocado precisamente por el cambio realizado en el primer punto, ya que al iniciar la aplicación en 64 bits, cualquier instancia que se realice de ensamblados o dll's compilados en 32 bits, sencillamente 'casca'
Consideración Especial:
Vistos los dos problemas que nos aparecieron, entiendo que la directa hubiera sido configurar el IIS para que permitiera aplicaciones en 32 bits, pero, ¿dónde está la gracia si lo solucionamos tan rápido y sin tener que pensar?
Nota: El segundo problema (ensamblado Interop) en este caso parecía claro que era por una compilación en 32 bits, eso NO quiere decir que en todos los casos esta solución sea válida al 100%.
Problema:
Al acceder a la dirección web de la aplicación, se produce una excepción de ASP.NET del tipo BadImageFormat.
Solución (¿solución?):
Fácil (yujuu!) El equipo en el que la aplicación está instalada es un Windows 7 en 64 bits, con lo que si está dando esa excepción, el sospechoso más habitual indica que el proyecto en Visual Studio está compilado en 32 bits, así que para solucionar el problema, basta con acceder a las propiedades del proyecto y especificar que la compilación sea compatible con 'Any CPU', tal y como vemos en la siguiente captura (Como el proyecto es en VB.Net, la captura corresponde a las propiedades de un proyecto en ese lenguaje)
Listo. Cambiamos la opción de compilación, compilamos la solución y la instalamos, y a funcionar… un momento, ¿no funciona?
Problema 2:
Al acceder a la aplicación ya compilada correctamente, aparece una nueva excepción. Esta excepción, de la que no tengo captura, decía que no podía cargarse en memoria uno de los ensamblados referenciados por la aplicación (en concreto se trata de un ensamblado Interop) toca 'bucear' un poco en la excepción y darle un poco al 'coco'… Vale, ya lo tenemos!!!
Solución 2:
La segunda excepción está directamente relacionada con la primera, ya que al compilar la aplicación para 'Any CPU' hemos conseguido que la aplicación arranque correctamente en IIS (64 bits) peeero cuando esa aplicación realiza una instancia del componente Interop (compilado en 32 bits) resulta que no puede crear los objetos porque no son compatibles. Menos mal que IIS 7.5 tiene la opción de permitir aplicaciones en 32 bits… ¿dónde?
Vamos al listado de los Application Pools, y en el Pool asociado a la aplicación vamos a las opciones avanzadas:
Aceptamos el cambio, IISReset por si acaso, y a volar!!!!
Explicaciones:
El primer error como he comentado estaba provocado por el tipo de compilación del proyecto. Al compilarlo en 32 bits, los procesos de IIS que se ejecutan en 64 bits no eran capaces de arrancar la aplicación, con lo que cambiamos el modo de compilación a 'Any CPU' para que el compilado sea capaz de adaptarse tanto a 64 como a 32 bits (opción recomendada)
El segundo error estaba provocado precisamente por el cambio realizado en el primer punto, ya que al iniciar la aplicación en 64 bits, cualquier instancia que se realice de ensamblados o dll's compilados en 32 bits, sencillamente 'casca'
Consideración Especial:
Vistos los dos problemas que nos aparecieron, entiendo que la directa hubiera sido configurar el IIS para que permitiera aplicaciones en 32 bits, pero, ¿dónde está la gracia si lo solucionamos tan rápido y sin tener que pensar?
Nota: El segundo problema (ensamblado Interop) en este caso parecía claro que era por una compilación en 32 bits, eso NO quiere decir que en todos los casos esta solución sea válida al 100%.
martes, 6 de septiembre de 2011
Los Informes de TFS 2010 no funcionan (no funcionaban)
Ayer al instalar las plantillas de Scrum para TFS 2010 de Microsoft (Visual Studio Scrum 1.0) me di cuenta de que los informes de estado de TFS no estaban funcionando. Estos informes son los que se utilizan para revisar el estado de un proyecto en TFS (Tareas finalizadas / pendientes, número de Bugs, etc)
Lo que sucedía es que cada vez que accedía a uno de los informes, el servidor de Reporting devolvía este error:
"Error al procesar el informe. (rsProcessingAborted)
Error de ejecución de consulta para el conjunto de datos 'dsBurndown'. (rsErrorExecutingCommand)
Para obtener más información acerca de este error, vaya al servidor de informes en el equipo del servidor local o habilite los errores remotos"
Error de ejecución de consulta para el conjunto de datos 'dsBurndown'. (rsErrorExecutingCommand)
Para obtener más información acerca de este error, vaya al servidor de informes en el equipo del servidor local o habilite los errores remotos"
Tras mucho mirar por ahí y realizar pruebas, la solución resultó ser 'medianamente' sencilla.
El problema, por lo que pude comprobar estaba en el procesamiento del cubo OLAP explotado por los informes. Por lo visto, la primera vez que se tiene que procesar el cubo no funciona directamente desde la herramienta del SQL Management Studio, sino que hay que hacerlo a mano.
¿Cómo lo hacemos a mano? TFS dispone de una serie de Servicios Web de administración que, entre otras cosas, permite precisamente eso. El servicio web en concreto es el que se llama "WarehouseControlWebService" la url de acceso es: http://servidorTFS:puerto/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx
Una
vez que accedemos al Servicio, hacemos clic en la operación "ProcessAnalysisDatabase", establecemos el valor del parámetro "processingType" a Full (tal cual está escrito, es un parámetro de tipo string) y hacemos clic en "Invoke"
Una vez realizada esta operación, teóricamente deberíamos ser capaces de procesar el cubo de nuevo desde el Management Studio, pero no lo he probado, ya que lo que quería era que los informes funcionasen y... voilá, funcionan!
NOTA: Conviene destacar que no he realizado un estudio en profundidad del problema, por lo que no descarto que vuelva a aparecer; simplemente me ha resultado de utilidad constatar que al regenerar el cubo mediante el servicio web de TFS los informes empiezan a funcionar correctamente. ¡Ya tenemos informes de "Sprint Burndown"!
Suscribirse a:
Entradas (Atom)