2

We have a strange issue with a silverlight app which seems to centre around the 'clientaccesspolicy.xml' file.

We have a website, which is the default website on IIS7. In the root of this website we have the 'clientaccesspolicy.xml' file.

We also have a web service defined in a 'http://thewebsite/asubdirectory/service.asmx' which handles some of the silverlight requests to the website.

What seems to happen, is that when we try to load the silverlight component, there is an http request for 'http://asubdirectory/clientaccesspolicy.xml' which is clearly wrong.

What's odd, is that if I setup the default website to be blank, and setup this particular website as an application/virtual directory below the default website. e.g. http://thewebsite/subdomain/ then the request for clientaccesspolicy goes to http://thewebsite/clientaccesspolicy.xml and assuming I keep a copy of the file at the root of the default website, things work ok.

What I'd like to know, is how silverlight/IIS is determining that it needs to look further up that the root for the clientaccesspolicy when the website is defined as the default.

Could it be the service location or the service references in silverlight? Is there a sensible way round this?

Many thanks,

Doug

RobSiklos
  • 8,348
  • 5
  • 47
  • 77
dougajmcdonald
  • 19,231
  • 12
  • 56
  • 89

1 Answers1

2

Silverlight needs to ask target site for cross-domain policy if it is not the same domain. So based on your "http://asubdirectory" I think somewhere your code is wrong and actually tries to use service at http://asubdirectory/someservice location instead of http://thewebsite/asubdirectory/someservice.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • I think you're right Alexei, I was hoping to avoid going into the code if the paths are something provided by either IIS or the silverlight app but I think there is no option! – dougajmcdonald May 08 '12 at 20:12
  • 1
    You were right Alexei, this whole puzzling situation was caused by someone writing a code block designed to pull in the 'ApplicationRoot' value from the URL and respond to that. Since without a virtual directory it just has '/' as the ApplicationRoot that code block was navigating too high up the URL and returning 'http://' rather than 'http://thewebsite/' – dougajmcdonald May 09 '12 at 09:17