WCF common types not reused

Referencing the shared assembly before adding the service reference does not work

You would need to do this, or at least update the service reference after adding the reference.

Deleting and re-adding the service reference (or the shared assembly reference) did not help

and you shouldn't need to do this, but I would've tried it too.

In order for the 'reuse' to work both projects (client and service) need to be using the same version of the assembly. You're referencing the project, which is good - I've encountered this before when referencing the assembly directly because of different versions.

Here's some other things to try

• Open 'Configuration Manager' for your solution - make sure that the shared assembly is configured to build.
• Ensure you're using a project reference for both client and service - using the latest assembly on the client won't help if the service is using an older version.
• Delete the project reference and build, and expect the build to fail - if it doesn't fail then you must be referencing something else.
• Manually check that the latest 'shared assembly' is being included in the build in both service and client - check the bin folder, check the assembly version / build date.

If all else fails, the best way to force the same object on both sides is to remove the 'service reference' proxy altogether and use the ChannelFactory method. See Simpler Explanation of How to Make Call WCF Service without Adding Service Ref and VS2010 Advantages of Add Service Reference over direct ClientBase<>. This is my preferred WCF pattern because it removes the need to 'Update service reference...', and removes all that generated proxy code.

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.

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.

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.