*Moved to: http://fluentbytes.com/silverlight-error-messages-can-be-very-cryptic-or-even-inappropriate-sometimes/
The past few days I have been working on a simple proof of concept where we want to replace some of the dashboards we have that where build in Flex/Flash with Silverlight 3 controls.
The reason to switch has most to do with the fact we can maintain all our codebase with one single technology instead of having many different technologies. The proof of concept just needs to show we can get the same functionality and have better development and debugging experience then we have today.
So during some work I did, I needed to just call an existing web service that already has an crossdomain.xml file deployed on the website. Now it happens to be that this web service is part of our SharePoint portal. Once I created the proxy by just adding a web reference, I created the simple code to call the service and wait for the data to get back:
DisplayNames.DisplayNameSoapClient client = new BuildStats.DisplayNames.DisplayNameSoapClient(); client.GetViewDataCompleted+=new EventHandler<BuildStats.DisplayNames.GetViewDataCompletedEventArgs>(client_GetViewDataCompleted); client.GetViewDataAsync("Budget (Earned Value)","Highlight");
As you can see very simple code. Now when I tried to get this code to work, I constantly got the same exception message time and time again, and I just could not understand what was going wrong.
The message I got was the following:(XXXX is the name of the server I just left out)
An error occurred while trying to make a request to URI ‘http://xxxxxx/sites/endstp/dev/_vti_bin/DisplayName.asmx’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
It took me a very long time to get my head around what was happening here, since I used the same service as the flex control was using and we already had the crossdomain.xml deployed. I used fiddler to see if the crossdomain.xml file was retrieved and I could see it did get the file. So what was happening here? Well as after reading the message over and over again, I finally picked out the following part of the message: “or a policy that is unsuitable for SOAP services”
It happened to be that the way the flex control retrieved the data was different the I did with Silverlight. Therefore I needed to alter the crossdomain.xml file to also include a SOAP call. So the file I now used looks like follows:(See bold line that fixed the problem for me)
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*" secure="false" /> <allow-http-request-headers-from domain="*" headers="SOAPAction"/> </cross-domain-policy>
I know for production use we should not allow just anybody to do calls against our server, but since this is only used during development, this is fine for me now. Once the control is implemented it won’t be making cross domain calls anymore and I don’t need the file. (it is not a part of the deployment package)
So after fixing that I was able to get the data and plot the simple graphs based on the data I got. So all was good again.
But then one day later, I started some additional work on the same project and I got the exact same error message again!?!?!?
So how could that be? I wanted to start and see if the cross domain file might be incorrect or changed by someone else and then I found that the network was not even up and running! So I just simply forgot to plug in my network cable before I start to work and I got the exact same message!
Now I must say that encrypting an error message in such a way it will take a while to figure out what is wrong is one thing, but using the exact same message while there is not even a network available, just beats me. I know that with security in mind, you don’t always want to provide a lot of diagnostics what might be the issue, but just giving everybody a walk around the park with a generic message , just makes no sense to me. I really hope this is not a new trend in security practices.
Follow my new blog on http://fluentbytes.com