WmsLayer failure

[ZachPride]

Hey everyone,

I've been using the WmsLayer for my WMS Service needs, rather than my old way of doing things by sussing out a GetMap URL and posting that image to a GraphicsLayer. It's been working well but I seem to have found a service that breaks it.

Here is the getCapabilities URL I'm using:

http://ags.pdc.org/arcgis/services/global/pdc_active_hazards/MapServer/WMSServer?SERVICE=WMS&REQUEST=GetCapabilities

I'm able to to get the Name of the layers available (they're using simple numbers to ID them). I provide the WmsLayer the  getCapabilitiesURL, the layer ID number & a Proxy Url based upon the proxy handler from the documentation here at ESRI. Unfortunately that doesn't seem to be enough. When debugging, I crash to an unhandled exception as soon as I add it to my map control.

Category: ManagedRuntimeError
Message: System.InvalidOperationException: Sequence contains no elements

Using Firebug to look at my hosted application, it reports this error:

Unhandled Error in Silverlight Application Data at the root level is invalid. Line 1, position 1.   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
   at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
   at System.Xml.Linq.XDocument.Parse(String text, LoadOptions options)
   at ESRI.ArcGIS.Client.Toolkit.DataSources.WmsLayer.client_DownloadStringCompleted(Object sender, DownloadStringCompletedEventArgs e)
   at System.Net.WebClient.OnDownloadStringCompleted(DownloadStringCompletedEventArgs e)
   at System.Net.WebClient.DownloadStringOperationCompleted(Object arg)

The XML returned by the GetCapabilities call seems sound to me - at least it appears like all of the other WMS services I've been communicating with - so I'm not sure what parsing errors it is running into. Any ideas? I can provide further info if there is something I haven't thought to check.

[DominiqueBroux]

I can't reproduce with the latest API version (3.0).

[ATTACH=CONFIG]14416[/ATTACH]

Which version are you using?

[ZachPride]

Oh, I did not know there was a newer version out. I'm working with 2.4 from January. I'll see what happens with the newer API.

However, based upon my projects requirements I might need to continue supporting Silverlight 4... Are there known modifications to WmsLayer in 3.0?

[DominiqueBroux]

I eventually tried with ArcGIS 2.4 and I didn't reproduce the issue either.
I added this layer to the interactive SDK sample:

<esri:WmsLayer ID="OtherWMSLayer"                      
                          Url="http://ags.pdc.org/arcgis/services/global/pdc_active_hazards/MapServer/WMSServer"                     
                          ProxyUrl="http://serverapps.esri.com/SilverlightDemos/ProxyPage/proxy.ashx"                     
                          SkipGetCapabilities="False"                     
                          Layers="0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16" 
                          Opacity="0.9" />

and got this result :
[ATTACH=CONFIG]14476[/ATTACH]

Could you give more info on how to reproduce the issue.
Thanks.

[ZachPride]

Thanks for giving this a try dbroux. You've hightlighted an interesting distinction here.

I put in the WMS Layer as you did in XAML, at design time and got the expected results. What we're doing is giving users a basic form control that lists the layers available from a WMS service and letting them add them. so I've created and added WmsLayers in code behind. What is interesting is the URL I've been giving the WmsLayer.

Keeping everything else the same, if I give it the URL:

wLayer.Url = "http://ags.pdc.org/arcgis/services/global/pdc_active_hazards/MapServer/WMSServer";

It works just fine. I can set the Layers property to the chosen ID and get anything I like.

However I was prior setting the URL to this:

wLayer.Url = "http://ags.pdc.org/arcgis/services/global/pdc_active_hazards/MapServer/WMSServer?service=wms&request=getcapabilities";

Which resulted in the crashes and errors I stated in my first post. I'm supposing that internally the WmsLayer constructs the necessary URL parameters for the getCapabilites request itself and that I was throwing it off by setting params in the URL string?

[DominiqueBroux]

OK that explains your issue.

You don't have to add the parameter 'request=getcapabilities' to the WMS layer URL. The type of request (get capabilities, get image, get legend, ...) is automaticlly added by the WMS layer depending on the current type of request.

[ZachPride]

Okay so I'm still hitting an issue with this thing. I have the URL property set properly now: http://ags.pdc.org/arcgis/services/global/pdc_active_hazards/MapServer/WMSServer

I've got SkipCapabilities set to false & the ProxyURL set to my local proxy.ashx

When I run my application in debug in VS, it works. The layer is added and the overlay shows up. However, when I compile and host the site I get the same error I had in the beginning: Data at the root level is invalid.

I'm using this clientaccesspolicy.xml file:

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <!--It is almost always a security error for an HTTPS service to allow HTTP callers 
            since this allows the possibility for untrusted code to be injected into a legitimate service (a man in the middle attack) 
            and access data that is supposed to be secured via the HTTPS protocol.-->
        <domain uri="*"/>
        <domain uri="http://*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Since it works in debug it makes me think there is some kind of server configuration issue. Does a client access policy need to exist at the www root?

[DominiqueBroux]

Try using fiddler to look at the requests sent to the server. That might give a clue.

If your proxy is not in the same domain than your SL application, check that you set a crossdomain or clientaccesspolicy at the root of your proxy web server.