Re: Web Service Method Call Fails - WPF Discussion Boards

The body is alreadt wrapped in a try/catch block, and it works fine locally. The only reason I could think of why it would fail remotely is that the appropriate version of .Net wouldn't be installed, but I checked that, and the server has 3.5...

The first call (which fails) is simply returning a string that uses no .Net objects/methods to construct it.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

But what do you get when you log the exception? It sounds like a permissions issue is at fault here, so let's try to get to the bottom of that.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

Permissions where - writing the log file? FWIW, I also tried turning on the WCF tracing, but i don't get a log file.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

I actually meant you'd need to write out a log file (using log4net).

The permissions I was talking about was the permissions on the actual service itself.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

Well, I fingered out how to get the inner exception (and wrote a tip/trick about it Smile | :)

), and for your reading pleasure, here it is:

An exception occurred during the operation, making the result invalid.  Check InnerException for exception details.<br />
   at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()<br />
   at FMDashboard2.FMDashSvc3Ref.GetMetricDataCompletedEventArgs.get_Result()<br />
   at FMDashboard2.Objects.DataRetrieval.service_GetMetricDataCompleted(Object sender, GetMetricDataCompletedEventArgs e)<br />
============<br />
Inner exception: An error occurred while trying to make a request to URI 'https://myUrl/FMDash3.svc/secure'. <br />
                 This could be due to attempting to access a service in a cross-domain way without a proper <br />
                 cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may <br />
                 need to contact the owner of the service to publish a cross-domain policy file and to ensure <br />
                 it allows SOAP-related HTTP headers to be sent. This error may also be caused by using <br />
                 internal types in the web service proxy without using the InternalsVisibleToAttribute <br />
                 attribute. Please see the inner exception for more details.<br />
   at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)<br />
   at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)<br />
   at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)<br />
   at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)<br />
   at FMDashboard2.FMDashSvc3Ref.FMDash3Client.FMDash3ClientChannel.EndGetMetricData(IAsyncResult result)<br />
   at FMDashboard2.FMDashSvc3Ref.FMDash3Client.FMDashboard2.FMDashSvc3Ref.FMDash3.EndGetMetricData(IAsyncResult result)<br />
   at FMDashboard2.FMDashSvc3Ref.FMDash3Client.OnEndGetMetricData(IAsyncResult result)<br />
   at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)<br />
============<br />
Inner exception: <br />
   at System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)<br />
   at System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)<br />
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)<br />
============<br />
Inner exception: Security error.<br />
   at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)<br />
   at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)<br />
   at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)<br />

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

Are your clientaccesspolicy.xml or crossdomain.xml files visible? Have a read of this[^].

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

Visible? I have a ClientAccessPolicy.xml file in my web services's folder:

XML

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from http-request-headers="*">
                <domain uri ="*" />
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
            </grant-to>
        </policy>
    </cross-domain-access>
</access-policy>

I also have a CrossDomain.xml, but I'm not really sure where to put it, so I have it in a few places.

XML

<?xml version="1.0" encoding="utf-8" ?>
<cross-domain-policy>
	<allow-http-request-headers-from domain="*" headers="*"/>
	<strong>
		<allow-http-request-headers-from domain="*" headers="SOAPAction" />
	</strong>
	<allow-https-request-headers-from domain="*" headers="*"/>
	<strong>
		<allow-https-request-headers-from domain="*" headers="SOAPAction" />
	</strong>
</cross-domain-policy>

Where *should* I put it?

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

You only need the ClientAccessPolicy.xml file. I notice from the exception that you are using https - in the allow-from section, you need to add

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

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

doesn't this accomplish the same thing:

<domain uri=”*” />

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

No.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

Ok then, but wouldn't it be more correct to do this?

XML

<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from http-request-headers="*">
                <domain uri ="http://*" />
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
            </grant-to>
         </policy>

         <policy>
             <allow-from https-request-headers="*">
                 <domain uri ="https://*" />
             </allow-from>
             <grant-to>
                 <resource path="/secure" include-subpaths="true"/>
             </grant-to>
         </policy>
    </cross-domain-access>
</access-policy>

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

If this is the way your site is set up, then yes. Alternatively, you could put both the https://* and http://* in the first allow-from if you don't have to worry about the secure path.

The reason you have to add the https://* is because SL requires that you explicitly opt-in to secure services.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

Well, I went ahead and made that change, and it still gives me the same exception. :/

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

I'd offer to test it for you but I'm running SL4 now.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

I saw a comment on the web that stated moving to SL4 fixes this problem. I don't have that option. I'm going to try putting the SL app on the same server as the service and seeing if that will fix it.

EDIT ========

Nope. In fact in some ways, it made it worse...

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

modified on Wednesday, June 9, 2010 2:59 PM

What happens if you drop it out of https into http?

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

I can't. It all has to stay https (DoD network).

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

Even for testing? Is there not an internal test rig that could be used for this?

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

Unfortunately no.

I do know for a fact that the app/web service work fine on my dev box. However, we haven't been able to get it to work when deployed. Because we're on a DoD network, it all has to be through https.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

I thought the crossdomain xml files had to be at the root of the site?

I had it there, and in the silverlight app's folder (just in case). It didn't seem to make a difference.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

This[^] looks similar to your problem. Check if it helps.

Nope, didn't help...

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

From whatever I have read so far, there are two reasons apart from the one in the link I had posted which can cause this:

1. Out of date service reference.
2. Long messages in response.

But most of the posts related to this have remained unanswered. Since I have never faced it, I am not sure. Just check if the references are fine and messages aren't larger than the default size.

BTW, how about .Net source debugging, it might tell what exactly is wrong.

I can double-check the reference thing, but:

0) The same app/service combination works on my dev box

1) I'm pretty positive that the DLL itself hasn't changed because I've only been monkeying with the web config to get it to even be browsable.

... but I'll double check anyway.

The response I'm expecting (a string) is less that 150 characters. Even if it was larger, maxReceivedMessageSize="2147483647", and maxBufferSize="2147483647"

I thiink it's a configuration problem. This is a https situation.

I found one guy that said he moved to silverlight/dotNet 4, and all his problems magically went away. Unfortunately, that's not an option for me.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001