WebBrowser + Mango = IE9

El otro día me llegó al correo una pregunta que, como de costumbre, no supe responder. Me preguntaban si podíamos esperar que WebBrowser utilizara IE9 como navegador en Mango.

Lo primero que me sugería la lógica es que sí. WebBrowser había estado utilizando IE7 hasta ahora y, puesto que Mango trae como una de sus principales novedades IE9 como navegador, lo normal era esperar que fuera así.

Rebuscando por MSDN (ese sitio donde está toda la información pero es casi imposible encontrar nada), encontré un pequeño artículo sobre los cambios e incompatibilidades de Mango en el que, explícitamente, citaban a WebBrowser y decían lo siguiente (traducción de cosecha propia):

El control WebBrowser para Windows Phone se ha actualizado para soportar Internet Explorer 9. Las aplicaciones que usen este control deberían re-testearse para asegurar su compatibilidad con Internet Explorer 9.

Parecía suficiente, pero ya que tengo instalado Mango en el teléfono, decidí probarlo por mí mismo. Creé un proyecto en el que simplemente incrusté un WebBrowser y una caja de texto para meter una dirección. El resultado lo podéis en la siguientes imágenes, primero navegando a http://user-agent-string.info/parse para conseguir información sobre el User Agent String que está enviando el control WebBrowser.

MangoBrowser_7-31-2011_13.10.33.888

Y, en esta otra, navegando al test ACID3, que aunque no valga de mucho por ser muy poco exhaustivo, sí nos sirve para diferenciar entre IE7 e IE9.

MangoBrowser_ACID3_7-31-2011_13.14.50.684

En definitiva, WebBrowser en Mango SÍ funcionará sobre Internet Explorer 9.

Permisos a NetworkService en remoto

Hoy me he encontrado con una situación que, no siendo habitual, tampoco es tan extraña. Tenía una máquina con un servidor de aplicaciones IIS que hospedaba una aplicación web (unos servicios WCF, por concretar). El Application Pool sobre el que corría dicha aplicación web estaba utilizando la cuenta de Network Service de la máquina, y era preciso que accediera a una base de datos en otra máquina.

Parece fácil, ¿no? Pero, ¿cómo darle permisos a una cuenta que no está en nuestra máquina y que tampoco es una cuenta del dominio en el que se encuentran ambas máquinas? La primera pista la podemos encontrar en IIS.NET, en este post (en inglés). En él nos explican, entre otras muchas cosas, que cada cuenta Network Service de una máquina se convierte en una cuenta distinta cuando trata de acceder a recursos en máquinas distintas. Esta cuenta en la que se “transmuta” Network Service cumple el siguiente patrón:

<nombre_de_dominio><nombre_de_maquina>$

Con lo cual, si nuestra máquina XXX se encuentra en el dominio YYY, su cuenta “transmutada” sería: YYYXXX$. Fácil, ¿verdad? Ahora sólo haría falta dar permisos a dicha cuenta utilizando Management Studio, en el servidor de bases de datos al que queremos atacar. Sin embargo, aquí nos encontramos con otro pequeño problema: Management Studio no es capaz de reconocer dicha cuenta.

Por eso, en su lugar, tendremos que tirar de consola (o de una ventana de query del Management Studio) y ejecutar el siguiente procedimiento almacenado:

exec sp_grantlogin 'nombre_de_dominionombre_de_maquina$'

 

Y, ahora sí, refrescando la carpeta de Logins del servidor SQL Server, podremos a este nuevo login y configurarlo para que tenga los permisos necesarios para acceder a la base de datos que toca.

[WCF] Nombres de máquina incorrectos en WSDL

Nos había pasado anteriormente y nos ha vuelto a pasar: WCF nos generaba el documento WSDL con el nombre de la máquina, no con su dominio.

Esto hacía que, por ejemplo, una máquina con nombre XXX en un dominio YYY, aunque su WSDL estuviera accesible en http://XXX/Servicio.svc?wsdl, internamente las rutas del documento WSDL hicieran referencia a http://XXX.YYY/, lo que hacía el WSDL inservible.

Parece ser que, hasta WCF 4.0, la solución no era sencilla: había que parchear este "bug”, “feature” o como queramos llamarlo, tal como se explica en este KB de Microsoft: http://support.microsoft.com/kb/971842/en-us

Sin embargo, a partir de WCF se ha incorporado la corrección y ya podemos tirar directamente de XML y olvidarnos de DLLs. El fragmento sería tan sencillo como éste:

<behaviors>
  <serviceBehaviors>
    <behavior>
      <!-- Necessary to avoid problems with domain/computer names -->
      <useRequestHeadersForMetadataAddress>
        <defaultPorts>
          <add scheme="http" port="80" />
        </defaultPorts>
      </useRequestHeadersForMetadataAddress>
    </behavior>
  </serviceBehaviors>
</behaviors>

Con esto ya tendremos nuestros WSDLs enlazando internamente de forma correcta el resto de elementos de que se compone.

Rulesets y branches

Desde la versión 2010 de Visual Studio podemos configurar rulesets específicos para cada proyecto, que se guardan como ficheros con extensión .ruleset.

Esta nueva forma de gestionarlo es muy flexible y nos permite controlar cómo de estricto es Code Analysis a la hora de realizar el análisis estático de cada uno de los proyectos de nuestra solución.

Por supuesto, si todo el proyecto comparte unas mismas reglas, es perfectamente posible compartir un único fichero (la solución que, en mi caso, adopto el 99% de las ocasiones).

Puesto que los rulesets pueden definirse para cada proyecto, dicha configuración se refleja en el .csproj. de dicho proyecto. La buena noticia es que la ruta es relativa, con lo cual en el momento de crear nuevas ramas, no tendremos ningún problema. La nueva versión del .csproj en la nueva rama hará referencia directamente a la nueva versión del fichero .ruleset que también habremos brancheado (ojo con esto si estamos haciendo branches parciales).

Sin embargo, hay un comportamiento no deseado: cuando se mueve un proyecto, la ruta relativa no se actualiza. Por lo tanto, deja de hacer referencia a nada que exista, al haberse desplazado la posición del fichero .csproj.

En este caso, al compilar en Visual Studio, recibiremos un warning avisando de que, al no haber podido cargar el ruleset para el proyecto, no se ha ejecutado Code Analysis.

La solución es fácil: abrir las propiedades del proyecto y volver a seleccionar el ruleset correspondiente a la rama en la que nos encontramos. Pero ojo al realizar esta operación, puesto que en el combo de seleccionar, por defecto, no vamos a ver ese fichero.

ruleset

En su lugar, sí nos va a aparecer una entrada relativa al fichero original, aquél del que hemos hecho el branch, y es muy sencillo no percatarnos de ellos y elegirlo (puesto que, al ser nuestro branch una copia, tendrá el mismo nombre).

En definitiva, los rulesets y los branches funcionan perfectamente, pero debemos tener cierto cuidado en caso de que movamos alguno de nuestros proyectos. En tal situación, actualizar las propiedades del proyecto con cierto cuidado de no elegir el ruleset equivocado.

CollectionAssert.AreEqual vs CollectionAssert.AreEquivalent

Como parte de mi trabajo diario tengo que hacer bastantes tests unitarios. Por esta razón me he ido familiarizando con las distintas clases que el framework de testeo de Visual Studio nos ofrece al respecto.

Una de las últimas que descubrí pero, por otra parte, de las más útiles, es CollectionAssert. Esta clase permite realizar aserciones sobre colecciones y listas, como su propio nombre indica.

Dos son los métodos que más frecuentemente utilizo, pero cuya semántica es lo bastante parecida como para merecer una explicación un poco más detallada:

  • AreEqual: este método compara dos colecciones y se asegura de ambas tienen los mismos elementos, en el mismo orden y la misma cantidad.
  • AreEquivalente: este método, sin embargo, simplemente comprueba que ambas colecciones tengan los mismos elementos y en la misma cantidad, sin importar el orden en que se encuentren.

Por lo tanto, AreEqual no es más que una versión más restricctiva de AreEquivalent, útil si queremos hacer una aserción más precisa en nuestras pruebas.