WCF Service that returns a custom class generates errors in Reference.cs

Question

I have a WCF Service project in Visual Studio 2008 that contains about 12 methods, some of which return primitive types like bool or string. I also have a Visual Studio Unit Test Project that references the published WCF Service. The Test Project compiles successfully when all the return types are primitive.

If I add a new method to the service that returns a custom class, publish it and update the service reference in the Test Project, it doesn't compile. The errors are: -

1. The type 'PublisherFaultException' already contains a definition for 'Reason'.
2. The type 'PublisherFaultException' already contains a definition for 'PropertyChanged'.
3. Type 'Publisher.Test.LibraryReference.PublisherFaultException' already defines a member called 'RaisePropertyChanged' with the same parameter types.

all in the auto-generated reference.cs file.

The contract for the method of the WCF Service is: -

Page GetItem(string path);

and the Page class has the DataContract attribute and it's public properties have the DataMember attribute.

I'm reluctant to modify the Reference.cs file as I'll need to do this every time the Service is updated.

Anyone know why this is happening?

Stuart.

Stereogram

what is happening is that WCF add service reference is a bitch - I feel your pain – Circuit

Have you tried to generate the proxy using svcutil? I remember having this issue before, and it was when I was creating custom fault exceptions using the FaultContract attribute. I don't remember the solution. So hopefully my comments could help. I'll keep digging and see if I can find the solution. Try SvcUtil.exe and see what occurs and let us know. – Pilkington

Answer 1

When you Add Service Reference, you get a 'reuse types in assembly' option - this is likely to be the key to sorting out the duplication.

Or do you have some Test References that are causing the duplication?

Also, have a look in the References section of the project tree and see if there is anything unexpected in there (do you have references to 2 assemblies that both contain Service References in the same namespace?).

Windhoek

The "Reuse types in all references assemblies" is selected. Should this be the case? The Page class belongs to an assembly that, while it is in the VS solution, is not referenced directly by the the test project. – Stereogram

Reuse is general works well, though there are [long-winded] arguments for steering clear of sharing contract in this way. Is PublisherFaultException in the contracts assembly? Is it marked with appropriate Contract Attributes? (I havent seen the exact case you're seeing, but I'd be root causing it by following the trail of references). I take it you've clicked on the show all files button on the top of the project explorer and looked in the references.cs to see the generated code in order to determine what it might be clashing with? – Windhoek

The PublisherFaultexception is in the auto-generated Reference.cs file when updating the Service reference. It contains two class declarations for PublisherFaultException (both partial classes which is fine), but both with the public Reason property, PropertyChanged event and RaisePropertyChanged method. The actual ReportPublisherException class itself is in the WCF project and does have the DataContact and DataMember attributes. – Stereogram

Then it sounds like the problem is that the 'sharing detection' isnt picking up the fact that it's 'already there'. Hence my suggestion in the last one that there is a Contract Attribute missing on your Fault class. Think it's [FaultContract]... – Windhoek

Answer 2

Using auto-generated proxy class it is always pain.

To handle situation like this I using separate assembly with data contract classes and service interface.

Contract dll will have:

public interface IService
{
    [OperationContract]
    List GetContentList();
}

[DataContract]
public class ContentItem
{
  [DataMember] public string Name;
  [DataMember] public object Data;
}

The client will have reference to the Contract.dll. Proxy will be created manually:

class ServiceProxy : ClientBase<IService>, IService
 {
  public List GetContentList()
  {
   return Channel.GetContentList();
  }
 }

The server dll will have reference to the same Contract dll. So we will be able to avoid any errors with auto generated proxy. Also the manually created proxy will be simpler, more manageable.

Tillietillinger

Answer 3

When adding the Service Reference, try clicking Advanced, and select "Generate asynchronous operations".

I think what was happening was that there were some asynchronous methods in the web service, with names ending in "Async", which would conflict with the methods generated in the References.cs.

e.g. imagine the web service contains 2 methods: (1)SayHello and (2)SayHelloAsync.

Generating using the default task-based method produces:

• SayHello and SayHelloAsync for (1)
• SayHelloAsync and SayHelloAsyncAsync for (2).

The conflict occurred because there were 2 generated methods called SayHelloAsync.

At least I think that's what was going on. Anyway setting "Generate asynchronous operations" worked for me.

Brazilin