I am using a silverlight with wcf and when I use the .web project then it runs but when use the silver light project to run the following exception throws:
An error occurred while trying to make a request to URI 'http://localhost:9000/Services/BLWCFSvrc.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. 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.
I want to use the silverlight project to debug my code
Thanks in advance
In order to access network resources from Silverlight, the domain hosting the resource must provide a client access policy file; this is designed this way for security reasons. See here for details: http://msdn.microsoft.com/en-us/library/cc645032%28VS.95%29.aspx
I think your problem is different that just having the clientaccesspolicy.xml, the fact that it runs under the web project, means that you are delivering policies, if you have those added as seperate files under the web project then they wont be deployed when you run the SL3 app seperately, but im sure you figured this out and you're delivering the policies via WCF using webHttp binding (RESTful style), if not, you should.
I think the problem is that when you run the webproject, it builds to your local IIS and executes from there, IIS will allow the SL3 app to communicate with ports/addresses different from the ones that the site is hosted on
when you run SL3 app natively, VS2008 auto generates a test html site for it to be hosted in with some default settings, and uses VS2008 built-in hosting service, which does not allow communication to an address/port different from that of the hosting address. (even though Silverlight is a client side library, VS2008 can do this)
so if you want to run the Silverlight application natively, meaning actually executing the XAP, you can deploy it to IIS, and configure IIS to deliver XAP files, or just install it and run it out of browser and let it update from IIS the deployed version
Just copy a clientaccesspolicy.xml file (for an example take a look at this post; you can even use this sample) into the root of your webserver (eg: c:\inetpub\wwwroot\).
This should help.
Related
Is it possible to access Rally's SOAP services from Silverlight? I am able to access the service from a .NET 2.0 proxy in a desktop application, but not via a WCF client proxy in Silverlight. I get the following familiar exception,
System.ServiceModel.CommunicationException:
An error occurred while
trying to make a request to URI .... 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.
I believe the problem is caused by trying to make a cross domain request from Silverlight, which requires a cross domain policy file installed on the server. If this is the case, why does the desktop application not require such a policy?
I'm not a Silverlight expert, but this looks like a cross-domain scripting/security sandbox that Silverlight imposes to make sure that Silverlight clients don't make requests to sites other than the server/host from which they were downloaded, unless the Silverlight client is specifically granted that right by the service provider/devloper. In the error message above:
"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."
I think the "owner of the service" means the owner of the Silverlight host, rather than the "external" webservice (in this case, Rally).
Desktop and/or console apps wouldn't have this same sandbox restriction. You would probably encounter the same issue trying to access another vendor's webservices via a Silverlight client.
You might find this Silverlight-specific thread:
Cross Domain Policy
Helpful for the specifics of how to setup and configure a Silverlight cross-domain policy file on your server.
Silverlight was built with security in mind. That means cross site scripting from the Silverlight application is turned off by default and must be enabled on a case by case basis. A .NET desktop application, on the other hand, generally has far greater security permissions and can call whatever web services, COM objects, and native APIs it pleases.
The way you work around this issue in Silverlight is to create a service on your server. The Silverlight client code calls your server side service which in turn calls a third party web service. The server side service can bet .NET, java, whatever. Web servers can generally call whatever they like -- problem solved.
Resolved this myself by using the extended permission features available in Silverlight 5. Since the xap is deployed on an internal internet, this solution was acceptable.
I am new to silverlight. I have been trying to patch up a silverlight app that makes a get request to some site over the net, say google. However, I keep getting the system.security exception again nd again. I read various other posts and what i gathered is that for these things to work u need to choose HOST APPLICATION IN A NEW WEBSITE option while creation of the project, i have done that, but still get the same exception. I downloaded the app from http://www.shinedraw.com/data-handling/flash-vs-silverlight-simple-http-post-request/ and ran it by clicking debug in VS2010, still it gave the same exception.
Please tell me what i am doing wrong, i know its cross domain issues, but dont know what else to do.
The second answer at this post - WebClient.DownloadStringAsync throwing Security Exception in Silverlight, I think, offers a workaround, but does this means there is no way to access such services from silverlight directly?? -
Experienced users please explain.
You cannot call a web service other than from your own domain directly from a Silverlight application. If you want to to this, you would have to install a cross-domain policy on the server that hosts the service. But you can always install a web service within your own web application (that hosts the Sivlerlight app) and call the other service from that service. It's one sercie call more but it works also with services you don't own.
I've got a Silverlight application that will be running out on the open internet, available to basically everyone who has ever lived.
The application makes use of RIA Services to manipulate data in a database on the server.
The application creates, reads, updates, and deletes data of different varieties, however I only want these operations to occur from within the application.
This brings about two questions:
Is there a particular recommendation for what type of Authentication to use? Forms or Windows?
Is there a way to prevent someone from "linking" to the application? That is to say, copying the HTML from the containing page, pasting it in their own HTML page on their local machine and running it? The end goal would be to only allow the application to be run when it is embedded in a page requested directly from my server and my server alone?
If your application is being used on an internal network, then Windows authentication is best. Otherwise (as is your case) use Forms authentication.
Silverlight automatically prevents applications (unless they're running with elevated trust) from accessing resources on the Internet (web services, HTML, etc) that are not from the domain that the application originated from, unless that domain has a cross-domain policy file in its root. The Silverlight runtime prevents this (not the server), so this a client based security feature - not server based. By not having a cross-domain policy file in place on your server, your application will only be able to communicate with your domain services when it is run from your server (as you are after). The application will run, but calls to those services will fail.
You could always do a check for what domain the application originated from in code, and match it to a hard-coded domain name if you want to prevent the application running at all from other domains.
Hope this helps...
Chris
I'm getting the following error when I connect my Silverlight app to my WCF service. I host this wcf as a self host service.
An error occurred while trying to make a request to URI 'http://lmr-hero/iSponsorWebSite/projectService.svc/basic'. 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.
What are the possible reasons for this error?
If your Silverlight application is not hosted on the same domain as the service then you will need to put a clientaccesspolicy.xml or crossdomain.xml file on the server that hosts the service.
See this link for details: http://msdn.microsoft.com/en-us/library/cc197955%28VS.95%29.aspx
Right click the .svc file and hit view in browser. Check to see if it's even being hosted and running correctly first. That will give you a good starting place.
Be careful that you set up a WCF web service correctly in Silverlight, when using Silverlight to consume the web service. Unlike a console mode client, in Silverlight you cannot just create a WCF New Item in your Solution, but must, under the .Web portion of your Silverlight solution, right-click, Add a New Item that is called "Silverlight-enabled WCF Service". Now you can go to the Silverlight app folder, add a Service Reference and you will not get this run-time error. This will avoid the run-time error the original poster refers to.
I've got a Silverlight application which uses a built-in .ASMX WebService to access a SQL database and run some queries. Everything runs without any hitches on my Development machine.
I'm trying to deploy the application to IIS 6 and I'm having some issues.
The Silverlight application itself seems to run fine, however the Web Service does not. I get an unhandled exception error that says [Async_ExceptionOcurred] as soon as the page loads (when the page loads I'm making some Async WebService method calls).
I think this is an issue with the Web Service but I don't know what the problem is. I tried setting the WebService namespace to my URL, but that didn't work. I've tried messing with the SQL connection string in my Web Config but that also affects nothing.
One thing to note is that my IIS Virtual Directory only contains my SilverlightApp.Web folder. I know that the other folder that's part of the application contains a .ClientSettings file for the WebService, but I think this is embedded into the .xap.
Can anyone shed any light on this?
The most likely thing that's happening:
Your webservice proxy on the client is using the address of the web service it was built against: ("http://localhost...").
Things to do:
Use fiddler to confirm this is the issue. It will show you where the proxy is making the call to.
Use the overloaded constructor for the web service and specify a URI. Consider using id/deffing for debug/release. This will overwrite the settings in the client.config.
Create another endpoint in the client config for the release build (Shawn's article here) and select one or the other (again using if/defs).
There are other options as well (looking at the URI and building up the service adress)... but that's the general idea.
hth,
Erik