Service reference not generating client types

Question

I am trying to consume a WCF service in a class library by adding a service reference to it. In one of the class libraries it gets consumed properly and I can access the client types in order to generate a proxy off of them. However in my second class library (or even in a console test app), when i add the same service reference, it only exposes the types that are involved in the contract operations and not the client type for me to generate a proxy against.

e.g. Endpoint has 2 services exposed - ISvc1 and ISvc2. When I add a service reference to this endpoint in the first class library I get ISvc1Client andf ISvc2Client to generate proxies off of in order to use the operations exposed via those 2 contracts. In addition to these clients the service reference also exposes the types involved in the operations like (type 1, type 2 etc.) this is what I need. However when i try to add a service reference to the same endpoing in another console application or class library only Type 1, Type 2 etc. are exposed and not ISvc1Client and ISvc2Client because of which I cannot generate a proxy to access the operations I need. I am unable to determine why the service reference gets properly generated in one class library but not in the other or the test console app.

Answer 1

You may have selected Reuse types in specified reference assemblies but not chosen the very important mscorlib library.

First click 'Show All Files' at the top of your Solution Explorer so you can expand out the service reference.

• Find the Reference.cs file and open it.
• Search for ClientBase in the source code to make sure you really haven't generated a client with a name you weren't expecting. If you find it then that's the name of your service client.

If nothing matches then right click the service reference and choose Configure Service Reference.

The important one is mscorlib which is required to properly generate the client. I like to select System.Xml.Linq also to get nice Linq classes like XElement and not XmlElement.

---

Still stuck?

• Tip: I always prefer to create a dedicated DLL just for the service reference. It can help if you need to wipe it out and start over, and it avoids certain chicken-and-egg compile problems once in a while.

• If you end up with half a References.cs file you may be 'reusing a referenced type' that is not compatible with your data contract. i.e. you've added data members on the server side, or changed the signature of an existing member such as making a value type optional.

• First, realize that SVCUTIL will quite happily generate an incomplete output file even if it has problems, and when running from Visual Studio you don't get the log file. Keep an eye in Explorer for the expected size and compare it to your 'last known good' size.

• Try to run SVCUTIL.EXE directly from a batch file (remember to save this file for next time)

• This is easiest to do in a Visual Studio Command prompt

• Sample command is as follows, note the reference parameter to the DLL that you are referencing types from.

  svcutil.exe http://dev.example.com/SSWPF.Web/Services/SS.svc /reference:bin\debug\RRStore.Sys.DLL

Detail: An exception was thrown while running a WSDL import extension:

System.ServiceModel.Description.DataContractSerializerMessageContractImporter Error: Referenced type 'SS.Sys.ShippingRateInfo, RRStore.Sys, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' with data contract name 'ShippingRateInfo' in namespace 'http://schemas.datacontract.org/2004/07/SS.Sys' cannot be used since it does not match imported DataContract. Need to exclude this type from referenced types. XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType[@name='ISSWCF']

Fortunately the answer here was simple, my type ShippingRateInfo had changed and I hadn't updated it. Once I copied this type over from the server everything compiled just fine (I chose to revert back to VS tool).

Answer 2

The real answer is, if you are serializing a type using the KnownTypeAttribute on your service contract, you MUST include a reference to your type's library in the project you are adding the service reference to.

For example, if your wcf service serializes the type System.Drawing.Image, then the consumer project MUST have a reference to System.Drawing. Hope this helps some folks out there.

Answer 3

I'd faced similar issue this is due to type mismatch. Because of which I was not able to generate the client in the test project. We maintain different versions of contracts, while creating new version I'd introduced type mismatch error. Following was the code scenario in my case.

Version 1 Contract

[DataContract(Namespace="http://www.exmample.com/v1")]
public enum Fruits
{
    [EnumMember]
    Apple,
    [EnumMember]
    Orange
}

Version 2 Contract

[DataContract(Namespace="http://www.exmample.com/v1")]
 public enum Fruits
 {
    [EnumMember]
    Apple,
    [EnumMember]
    Orange,
    [EnumMember]
    Mango
 }

I've resolved this issue using svcutil command line utility. Command

svcutil MyContract.dll

I got the below error message

DataContract for type 'V2.Fruits' cannot be added to DataContractSet since type 'V1.Fruits with the same data contract name 'Fruits' in namespace 'http://www.exmample.com/v1' is already present and the contracts are not equivalent.

I changed the namespace from version 1 to version 2 and I was able to generate service reference in test project.

[DataContract(Namespace="http://www.exmample.com/v2")]
 public enum Fruits
 {
    [EnumMember]
    Apple,
    [EnumMember]
    Orange,
    [EnumMember]
    Mango
 }

Make use of svcutil this will help to resolve this issue.

Answer 4

I encountered the same issue. Turns out my project was referencing a DLL directly instead of a project reference. So even though my project had a reference for the assembly, it was to an old version. Once I updated the DLL and updated the service reference everything was working again.

Answer 5

This normally happens for adding a service reference that you had added before. In the client config, it still has the relevant servicemodel. Make sure you delete the servicemodel from the client config and then try to re-add the service reference again!

Answer 6

Along the lines of @Kevin's answer, I added references to all the projects and DLLs referenced in the service project. The proxy generation was then able to recognise / generate the types required.

Once that's done, you could even then start to remove some and regenerate to exclude the redundant ones.

Answer 7

Apparently you have to add a reference to System.Web in your project before adding the Service Reference. That did it.