WCF common types not reused

Question

Hint: This questions has many duplicates, but none of the solutions works for me.

What I have is a web service and a client, both having references to a shared assem

Answer 1

After checking all the answers here, nothing worked. Then I realized that my service had an error when viewing the wsdl in the browser. This should be obvious right? Well, see what happened is I opened the service's solution file as a different(none admin) user and updated the name of one of the reusable types. Built my solution and everything built successfully. Which is when I ran into the issue described by the OP.

What happened was, because I logged in with a non-admin account and I wasn't using IIS express. My WCF project did not load. Meaning that the rename of the type did not take effect in the WCF project. Thus causing the issue.

TLDR; make sure your service actually starts and works correctly, before looking for issue in the consuming application.

Answer 2

I thought I would add another situation to the list of answers: if you have any types that inherit from a common collection, like Dictionary<K, V>, when you choose to reuse types, you either need to choose to Reuse types in all referenced assemblies, or, if you choose to Reuse types in specified referenced assemblies, make sure you choose the System assembly (home to the generic collections) in addition to the assembly that contains your data contracts.

In our situation our class definition was along the lines of:

public class FooMetadata : Dictionary<Guid, FooMetadataType>
{
}

Where FooMetadataType was a [DataContract]. Also note that you cannot decorate this class with [DataContract] because Dictionary is already marked as [Serializable]; your service will compile but upon deployment you will get a YSOD when browsing to the .svc file.

Answer 3

This is an old topic, but since I ran into the same problem today I want to share my fix.

For me the problem was that the shared assembly was correctly added in both projects (service and client), but on service side this shared assembly referenced another assembly that was not present on client side.

I noticed the error using Svcutil.exe with below statement. Open the commandline in the folder where SvcUtil.exe is located (for me this is C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools) and execute below statement after changing below segments (marked with <>):

SvcUtil.exe /t:code /language:cs  /r:<path of the .dll that contains the types to reuse on client side> <wcf service url>

make sure that the .dll of the types you want to reuse physically exist in the /bin folder (maybe not there due to build error,...). If needed copy a correct build from the service.

SvcUtil will try to generate service and/or data contracts based on the WSDL document from the specified service. The /r tag specifies where the .dll is located on the client side that contains the reusable types (just like you specify when using "Add service reference").

if there is a problem with reusing types it will be displayed in the command line when the statement is executed.

This can point you in the right direction where the problem lies in your shared assembly.

Answer 4

It is a bit of a long shot, but one possibility is that an old version of the shared dll is in the GAC.

It tries to use the shared dll, finds a dll with types missing, and then reverts to creating types.

Answer 5

OBJECTCEPTION!

We recently had the same problem where I work. It took us four hours to hunt down the problem, but we eventually discovered that an enum on an object within the same dll as the object it was refusing to copy had the same name as another enum that was being used in the service, so it refused to reuse any types from that dll.

Suggestion(solution?): Make sure that there are no other objects in the dlls, or objects on those object, or... etc. that have the same name as one in your service.

Answer 6

I just went through an entire day trying to find out why the Types in my shared dll were not being reused when I added a Service Reference in VS2013. It turns out that the service had several problems related to serialization. I had a couple of enumerations that did not have the EnumMember attribute. The way I solved my issues were by trying the following steps:

1. Commenting out all operations (methods decorated with OperationContract attribute) in my ServiceContract that did not return atomic Types.
2. Then updating my Service Reference in my client project. I realized that the problem had been resolved when in my client project, I was able type "[MyServiceReferenceName]." and my Types did not appear in the [MyServiceReferenceName] namespace. I verified this by opening the generated XSD files in the XML Schema Browser just to be certain.
3. One by one, uncomment a method that was commented in Step 1. Then update your Service Reference each time to see if the types are or are not being resued.
4. Once you find the method that is causing the Service Reference to fail to reuse Types, go to each class for the the Types that are either input or output to the method. Check that all classes that you wish to serialize are decorated with the [DataContract] attribute. Ensure that all fields and properties are decorated with the [DataMember] attribute. Also, ensure enums are decorated with [DataContract] and that each enumeration value is decorated with [EnumMember].

I hope this helps others who are going through this frustrating process and this problem is not necessarily related to a shared dll. My issue was not really an issue with using Add or Update Service Reference. The problem lied with my entity (model) classes not being decorated with the proper attributes to notify the DataContractSerializer to serialize those types. It seems that if any part of serialization fails, adding the Service Reference adds all the Types.