Does anyone know of a clever way to distinguish between an error communicating with a server due to a missing or invalid clientaccesspolicy.xml file vs. a server presenting an untrusted or self-signed certificate? This is a Silverlight 3 application talking to a self-hosted WCF service on a server.
Currently both cases are returning the generic CommunicationException with an inner SecurityException: "Security error" on the very first WCF call to the server. The exception types and messages are identical.
My Silverlight application is currently catching this exception and presenting a pop-up with an HTML page hosted on the WCF port in order to show the actual browser warning for the untrusted cert so they may accept it in the browser if they wish and reload the Silverlight application (with no more SecurityExceptions).
However, in the case that the server is actually offline Silverlight attempts to retrieve the clientaccesspolicy.xml file first which fails, and results in this same exact error on the first service call. I would prefer to show some kind of server offline message instead of my certificate pop-up mechanism in this case if there is a way to distinguish the two.
Thanks!
EDIT
If there is no way to distinguish the service exceptions between the two scenerios, would there be a way to manually request the clientaccesspolicy.xml in Silverlight BEFORE I make my initial WCF call? In other words, I would make some request to attempt to manually retrieve the clientaccesspolicy.xml for my WCF service right off the bat. If that failed, I would know that the self-hosted WCF service is not running. Otherwise I would proceed with my application startup and would know the SecurityException is due to an untrusted cert.
My understanding is that any usage of HttpWebRequest in a cross-domain manner would result in Silverlight requesting the clientaccesspolicy.xml file automatically anyway, which would put me back to square one. Any ideas?