Silverlight clientaccesspolicy.xml error? o diseño?

Question

En el nodo de dominio de un archivo clientaccesspolicy puede especificar un comodín para un subdominio o protocolo, pero no aparecerá para un puerto.

Específicamente cuando se desarrolla, si el servicio se consume está alojado en un tercero, entonces el acceso a una versión de depuración local de una aplicación Silverlight que se ejecuta en el servidor de desarrollo asp.net localhost funciona bien con los nodos:

<domain uri="*"/> 
<domain uri="http://*"/> 
<domain uri="http://localhost:1234"/> 

(donde 1234 es el número de puerto determinado específica)

pero parece que no funciona si se especifica en la forma

<domain uri="http://localhost:*"/> 

que es extremadamente molesto si hay varios desarrolladores/proyectos usando el servicio o no especifica un puerto para el servidor de desarrollo asp.net

¿Alguien sabe si el formato es incorrecto o es un error? o un descuido en el manejo de la política de acceso público por Silverlight?

Answer 1

El comportamiento que describes está en línea con la documentación, que establece:

Hay tres tipos de comodines permitidos:

Un autónomo comodín '*'. Esta opción se usa para permitir el acceso a todos los dominios del mismo esquema. Un servicio HTTP permitirá todas las llamadas HTTP. Un servicio HTTPS permitirá todas las llamadas HTTPS.

Un comodín literal "http: // *". Esta opción permite explícitamente todas las llamadas HTTP , incluso si se trata de un servicio HTTPS .

Un comodín de subdominio. Esta opción usa un comodín en el primer segmento de la ruta ("http: // .contoso.com", para el ejemplo ) que permite a todos los subdominios de el dominio especificado. Entonces para el ejemplo . http://web.contoso.com y http://mail.contoso.com serían permitidos. Tenga en cuenta que una ruta uri donde el comodín no aparece como un prefijo (http://web. .com, por ejemplo) no está permitido.

http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

Así que no hay nada sobre comodines para los puertos, los cuales (que tiene razón) no tienen ningún sentido cuando se permiten comodines para hosts y dominios.

Answer 2

solución alternativa:

Bajo Propiedades de su sitio web que aloja la aplicación SL, vaya a la pestaña Web, y cambiar el auto-asignar puerto a puerto específico .De esta manera, puede configurar su puerto localhost: 1234 en el archivo clientaccesspolicy como ya lo ilustró, y esperar que no necesite un cambio de puerto sin importar qué desarrolladores también usen el proyecto.

Esta no es una solución perfecta, ya que siempre es mejor asignar automáticamente en lugar de puertos fijos en los proyectos. Buts es una buena opción para probar.