locked
Silverlight/WCF communication Error (Maybe Cross Domain Issue) RRS feed

  • Question

  • I have built a web site that hosts a Silverlight app and a WCF service in the same project. Communication between the Silverlight App and the WCF service initially worked fine. Today, however, it stopped working and threw the following error ...

    An error occurred while trying to make a request to URI 'http://localhost:50934/Rpt50.Web/Rpt50Service.svc'. 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. Please see the inner exception for more details

    It could well be a cross domain issue because the service and the website hosting the Silverlight app have a different port number! I guess this begs the question why it worked originally or maybe why did the port numbers change. More to the point there doesn't seem to be a way of forcing the App and the service to use the same port number if I'm using the internal development server. I could (probably will) get around the problem by hosting the service in the workstation's IIS instance but that makes debugging more of a pain.

    I'm running Windows 7 ultimate RC1 (x64) on my desktop - don't know if that's an issue.

    Can anyone shed any light on this?
    Wednesday, June 10, 2009 1:44 PM

Answers

  • Due to Silverlight security restrictions, you need to expose a policy file on the service domain, if the service domain is different than the domain where the Silverlight control is hosted. The domain is defined as [scheme]://[host]:[port], so a difference in any of those would require that you expose a policy file.

    Check out these docs for more information on the cross-domain restriction.

    If you want to have the service and client on the same domain in Visual Studio, then make sure they are added to the same Web Application project. The simplest way is to right-click the Web Application that gets created when you create a Silverilght application, and add the Silverilght-enabled WCF Service template. This will ensure they stay on the same domain.

    Thanks,
    -Yavor

    Wednesday, August 19, 2009 7:51 PM
    Moderator

All replies

  • Hi there.
    One possibility is to use this solution from carlosfigueira:
    http://blogs.msdn.com/carlosfigueira/archive/2008/03/07/enabling-cross-domain-calls-for-silverlight-apps-on-self-hosted-web-services.aspx

    Thanks!
    Scott
    MS Developer Support
    Friday, June 12, 2009 4:30 PM
    Moderator
  • Due to Silverlight security restrictions, you need to expose a policy file on the service domain, if the service domain is different than the domain where the Silverlight control is hosted. The domain is defined as [scheme]://[host]:[port], so a difference in any of those would require that you expose a policy file.

    Check out these docs for more information on the cross-domain restriction.

    If you want to have the service and client on the same domain in Visual Studio, then make sure they are added to the same Web Application project. The simplest way is to right-click the Web Application that gets created when you create a Silverilght application, and add the Silverilght-enabled WCF Service template. This will ensure they stay on the same domain.

    Thanks,
    -Yavor

    Wednesday, August 19, 2009 7:51 PM
    Moderator
  • We can use messageHeaders to check and authenticate the connection between the Silverlight and WCF service. Operation context of type System.ServiceModel holds the information for the current operation in client and service side.

    For sending messages from the client side we will use the OutgoingMessageHeaders of type System.ServiceModel.Channels.MessageHeaders and similarly for receiving header information in service side we will use IncomingMessageHeaders.

    Suppose we want to send the username and password from the client and check in the service side we can use messageHeaders.

    Here in the client side we can create header with the CreateHeader function with the parameter CreateHeader(name as string,ns as string,value as object)

     

    Imports System.ServiceModel.Channels

    Dim PersonObj As New Person
    PersonObj.UserName = "Soumyap"
    PersonObj.Password = "Mindfire"

    Dim messageHeadersElementOutgoing As MessageHeaders = OperationContext.Current.OutgoingMessageHeaders
    messageHeadersElementOutgoing.Add(MessageHeader.CreateHeader("Authentication", "", PersonObj))


    Cheers, Eliza
    • Edited by elizas Wednesday, February 24, 2010 10:19 AM spelling check
    Wednesday, February 24, 2010 10:18 AM