Monday, June 16, 2008

Hasta la salida de la Beta 2 de Silverlight, cuando queríamos con la Beta 1 realizar una llamada un Servicio Web o WCF sabíamos que debíamos de colorar los ficheros Crossdomain.xml o ClientAccessPolicy.xml en el raíz del Sitio Web donde estuviese el Servicio a consumir por Silverlight. Silverlight por defecto irá a buscar el fichero ClientAccessPolicy.xml y sino lo encuentra buscará el Crossdomain.xml

Si hacemos pruebas desde Silverlight Beta2, nos encontraremos que aun teniendo estos ficheros, recibimos el siguiente error depurando:

El formato del fichero ClientAccessPolicy.xml que teníamos hasta ahora con el que conseguíamos que funcionase era:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Pero para esta versión necesitamos realizar un sutil cambio en el fichero:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Ahora si que funciona nuestro Silverlight.

Vamos por partes. Máquina con Windows Vista y Microsoft Visual Studio 2008 recién instalado. Creamos un nuevo sitio web y cuando queremos depurar, nos encontramos con esto:

¿Qué será?....El problema esta en el puñetero IPv6, y ¿Cómo deshabilitar esto?

Abrimos Regedit.exe y en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters añadimos un DWORD de nombre DisabledComponents y asignamos el valor decimal 255.

Después de reiniciar he conseguido que funcione, a pesar de que aunque el ASP.NET Development Server levanta un puerto, en el IE 7 intenta acceder a otro!!

Otro día busco porqué!