R – Silverlight – Good for Internet Business Application

In your config file, the endpoint address is http://dellnov2006:2753/SimpleWCF.svc So it seems that you are trying to connect to that address.

Before you publish the application you must modify that address to http://localhost/Service/SimpleWCF.svc or something to point exactly to your service.

The clientaccesspolicy.xml must be in **c:\inetpub\wwwroot** But you need this file only if you will access the service from different host that it was downloaded. I don't think you need it in your case, if you want to use localhost on the local iis.

First, a little philosophy...

If you are a consumer of a WCF service that you did not write, adding a service reference to your client is really the only mechanism you have to enable interaction with that WCF service. Otherwise, you have no way of knowing what the service contract looks like, much less its data and message contracts.

However, if you are in control of both the client and the WCF service itself, adding a service reference to the client is a nice convenience, but I've recently been convinced not to use it. For one, it becomes a nuisance after the first few times you change your contract to remember to update your service reference. And in my case, I have several different C# projects that are consuming the WCF service, so I have to remember to update each one of them. Second, creating a service reference duplicates the contract definitions that are already defined in your WCF service. It is important to understand the implications of this.

Let's say your WCF defines the following type.

[DataContract]
public class Person
{
    [DataMember] public string FirstName {get; set;}
    [DataMember] public string LastName {get; set;}
}

When you add a service reference to your client, the metadata associated with this class is retrieved through the metadata exchange (MEX) endpoint, and an exact replica of this class is created on the client side that your client "compiles" against. So your WCF service has a definition of the Person class, and so does your client, but they are two different, distinct class definitions.

Given this, it would make more sense to abstract the Person class into a separate assembly that is then shared between the WCF service and the client. The added benefit is that when you change the contract definitions within this shared assembly, you no longer have to update the service reference within the client because it is already referencing the shared assembly. Does that make sense?

Now to your question. Personally, I've only used WCF within C# projects, not Silverlight. However, I do not think things are radically different. Given that, I would suggest that you watch the Extreme WCF video at dnrTV. It gives a step-by-step guide for how to bypass the service reference feature.

Hope this helps.