I just completed one of my Silverlight 4 project. In this project I used Silverlight Enabled WCF service for handling my database operations. As the project requirements was just to read the data from the database via stored procs and display it on the datagrid. I intentionally didn’t use WCF RIA services as I thought this would be an overhead for this type of requirement. Both WCF Ria service (Domain Service) and Silverlight enabled WCF service works on the core principles of WCF technology. The difference is that lot of code is generated by Ria Services framework and there is no physical .svc file in your project whereas in the Silverlight enabled WCF service you have .svc file with you and things are more under your control. Both supports Asynchronous service operations. Besides this when you add a service reference to your Silverlight project from the solution a new file called “ServiceReferences.ClientConfig” is also created which plays key role, read further.
THE DEPLOYMENT GOTCHAS
The solution worked like a gem in my Visual Studio 2010 development environment , which uses Cassini web server. But when it came to deployment on IIS , I ran into issues. As usual the server returned the infamous error “NOT FOUND” to Silverlight client. I was already aware of RIA deployment problems and I tried all those steps but all in vain. Then Fiddler came to my rescue. This is awesome http debugging tool and I really love it. After analysing the fiddler output I was shocked that my .svc url was still pointing to the localhost. Holy crap what is that I was totally lost and didn’t know what was happening. Though my address attribute in the endpoint element of web.config file was pointing to the correct path of my IIS virtual directory, then where did I go wrong.
I didn’t gave up so easily , I started digging out forums , googling , binging whatever you can add over here. But could not find anything concrete which could solve this issue. Then Visual Studio intellisense helped me. I came to know that the proxy service class that was generated by Visual Studio has more than one constructor, five to be precise. The third constructor which accepts the two parameters endpointConfigurationName and remoteAddress. See the below screen shot.
From the code you can see it was matter of two lines which made me rest in peace. The code is pretty self explanatory. I declare the objUri variable and initialize with .svc path. As mentioned earlier here we have physical .svc file present and this should be also deployed on IIS. The Application.Current.Host.Source returns you the .xap file path and as my .svc file was located in the root of virtual directory I used ../ and the .xap file was located in the ClientBin folder. The second line of the code does the magic. Here I have used the endpointConfigurationName from the ServiceReferences.ClientConfig file. Remember what I told in the beginning. This is a string value which is auto generated by Visual Studio and finally the second parameter is fully qualified path of service file. After making these changes I rebuild the solution , did a deployment using Publishing Wizard and viola my application started working.
I am still in the process of finding that even though when I specified the endpoint address in the web.config file why the service was referring to my localhost. I thought that should have resolved the issue but it didn’t work. Now my address attribute in web.config is empty string and I am not require to deploy the ServiceReferences.ClientConfig file on IIS. It just simply works with these two magical lines of code. Hope this solution will help the community in their deployment issues and they don’t undergo the struggle period that I went. After all learning is all about sharing. Let me know your thoughts for the same.