Re: Re: Deployment of Silverlight App + Silverlight-Enabled WCF Service to Production
work2gs: Hi
I am in the same situation as GearWorld, anyone could provide a sample ?
I didn't find how to use WCF outside the vs2008 ????
thanks
Fred
There is nothing magical to call WCF outside VS2008. But you need to understand how things are working in every case:
If you are running under VS, your are using Dev Server by default. The Dev Server will dynamically set the Page URL and Service URL with a port number. Check the page URL on your browser, it should be something like http://localhost:PORTNO/YourTestPage.html. So when you add Service Reference to your Silverlight project, the Service URL would be http://localhost:PORTNO/YourService.svc.This url will be added to your ServiceReferences.ClientConfig file. Check that file you should see that.
When you call your web service, the ServiceClient has 5 consturctors, usually people just use the simplist one which does not take any
parameters.
var ws = YourService.YourServiceClient();
By using this constructor you rely on the setting in the
ServiceReferences.ClientConfig file.
When you deploy your web to IIS, the URL of your Page and Service will change. It no longer has that Port number in the URL. It should be something like http://YourServer/YourSite/YourTestPage.html and http://YourServer/YourSite/YourService.svc.
So you need to change the URL for your service in your ClientConfig file after you deploy your Web Site. Actually you need to do this before your last build, because the ClientConfig file will be packaged into the Xap (if you already deployed your Web site. You can use a WinRar tool to extract the ClientConfig file out of the Xap, modify it, then re-Zip it back to the Xap).
But you might still hit cross-domain issue even you changed URL in the ClientConfig if you did the following:
Service URL: http://YourServerName/YourSite/YourService.svc
Page URL: http://localhost/YourSite/YourTestPage.html.
This is considered a cross-domain call because the domain part of your page URL(localhost) and Service URL(YourServerName) are not the same even they are really pointing to the same place. In this case you need a clientaccesspolicy.xml file in your wwwroot folder. Otherwise you will get 404 error.
One way to avoid all these trouble is to use the 3rd method I posted in this thread: By passing the URL reading from the ClientConfig file. Dynamically build the Service URL and set it in code.
Instead of using the default constructor of the ServiceClient, you pass the EndPointName and Endpoint address in the constructor:
System.ServiceModel.EndpointAddress address = new System.ServiceModel.EndpointAddress(new Uri(Application.Current.Host.Source, "../YourService.svc"));
var ws = YourService.YourServiceClient("YourEndPointName", address);
By passing the EndPointName to the constructor, you still rely on the binding settings in the ClientConfig file. When Microsoft provide more binding options later, you can easily change the binding in the Config file.
This way you do not need to modify your ClientConfig file to change the service URL on each deployed machine, you do not even need the cross-domain policy file because the Service URL and Page URL will always from the same domain. This will work in both Dev server and IIS.
If you still have problem, you can change default Web Server to IIS while you debugging under VS. Just right click your Web project and select Web tab. On that tab you can change the Server to use IIS server instead of Dev Server. So you can hit F5 to debug, but the page and service are really running under IIS.
By the way, this post only applies to calling WebService under the same Web Project(or Web Site). If you are calling a Web Service outside your Web site or a 3rd Party web service, do not use the method suggested in this post.
sladapter
Software Engineer
Aprimo, Inc
Please remember to mark the replies as answers if they answered your question
