One of the biggest complaints about how Add Service Reference works for Silverlight applications is that the address it creates on the client config file (ServiceReferences.ClientConfig) points to the VS "test" web service (Cassini), something like http://localhost:12345/Service1.svc. It works perfectly when you debug on your machine (F5), but when you deploy it elsewhere (e.g., http://www.my.server.com/MyApp) it fails - the client will look for the service on localhost (instead on the real server) and it won't be found. There are some interesting ideas to overcome this problem. Tim Heuer posted about an approach with "production" versus "staging" endpoints in config at http://timheuer.com/blog/archive/2010/04/05/managing-service-references-in-silverlight-applications-for-different-environments.aspx. This is great, but I was looking for something simpler, where one wouldn't need to change the generated config file. On Silverlight 4, there's a new feature where you can have a relative address on the client address in config (http://blogs.msdn.com/b/silverlightws/archive/2010/04/05/dynamically-updating-proxy-address-for-staging-production.aspx), but again, that involved changing the generated config file. What I had been using (since Silverlight 2) has worked just fine for me, so I decided to post the solution here. The idea is that, in code, one helper function would take the actual page address (which, for the scenarios where you ASR to a service in the web project, is in the same domain where the .svc file will be), and based on that it will update the address of the client endpoint. The code is shown below (and a full project can be found here. Read more: Carlos' blog
Subscribe to:
Post Comments (Atom)
Posts
0 comments:
Post a Comment