Imported WCF Reference ignores Enum values

[markecw]

trafficstars

Imported WCF Reference ignores Enum values

When I add a Web Reference to a Core project, enum values are not imported. I am importing a service with many enums, most are not simple zero indexed sequence, therefore do not match the WSDL.

Framework Service Reference uses correct enum values.

Core or Standard projects, Enum values are not set so do not match the WSDL service. In a framework project, using advanced to add a "Web Service" results in the same unset enum values.

Unfortunately the WSDL is not publically accessable and I do not have permission to publish here, so edited snippet:

<xs:simpleType name="Constant.BobTypeEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="Bob ">
<xs:annotation>
<xs:appinfo>
<EnumerationValue>1</EnumerationValue>
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="Bobob">
<xs:annotation>
<xs:appinfo>
<EnumerationValue>2</EnumerationValue>
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="Bobobob">
<xs:annotation>
<xs:appinfo>
<EnumerationValue>3</EnumerationValue>
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="Obobobob">
<xs:annotation>
<xs:appinfo>
<EnumerationValue>4</EnumerationValue>
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="Ob">
<xs:annotation>
<xs:appinfo>
<EnumerationValue>6</EnumerationValue>
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>

Edited example of the correct framework generated reference:

  [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
    [System.Runtime.Serialization.DataContractAttribute(Name="Constant.BobTypeEnum", Namespace="http://schemas.datacontract.org/2004/07/bob.Constants")]
    public enum ConstantBobTypeEnum : int {
        
        [System.Runtime.Serialization.EnumMemberAttribute()]
        Bob = 1,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        Bobob= 2,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        Bobobob= 3,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        Obobobob = 4,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        Ob = 6,
    }

And last the Reference.cs snippet from a new standard project

   /// <remarks/>
    [System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Tools.ServiceModel.Svcutil", "2.0.2")]
    [System.Xml.Serialization.XmlTypeAttribute(TypeName="BobTypeEnum", Namespace="http://schemas.datacontract.org/2004/07/bob")]
    public enum BobTypeEnum
    {
        /// <remarks/>
        Bob,
        /// <remarks/>
        Bobob,
        /// <remarks/>
        Bobobob,
        /// <remarks/>
        Obobobob ,
        /// <remarks/>
        Ob ,
    }

[StephenBonikowsky]

@markecw Thanks for reporting this issue, we will look into it.

[sgarshol]

I've observed a similar behavior: If my ServiceContract interface includes an operation that return a result of the type System.Data.DataSet (don't judge!), the ConnectedServices tool or WCF (based on Svcutil v2.0.1 AFAIK) would...

• Not apply values to Enum members
• Apply message contracts regardless of whether or not that option was selected
• The selected collection type option (System.Collections.Generic.List) is ignored and the default is used (System.Array).

Omitting the apparently offending operation from the service contract, however, yields the expected result. So I guess I'll do that.

-S

[markecw]

Thanks, you appear to have found the problem. I saved the WSDL and edited to remove dataset references. There were also some bad xml tags, which I am unsure how they occured, but after more editing, the service can be imported. Resulting enums are correct, edited..

   public enum TConstantTypeEnum : int
    {
        [System.Runtime.Serialization.EnumMemberAttribute()]
        tte = 1,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        ttu = 2,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        ttr = 3,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        tti = 4,
        [System.Runtime.Serialization.EnumMemberAttribute()]
        ttp = 6,
    }

However I can not trust this work around and can not go to production. I hope this can be fixed so that we can move new projects to core rather than framework.

Thanks Mark

[StephenBonikowsky]

We do care about this and will be root causing the problem so we can get it fixed. We have a number of tooling issues right now and are working through them as quick as we can. Thanks!

[markecw]

Do you have an update or expected release for fixing this? our core project is now on hold until this is resolved.

[dasetser]

@markecw We don't have time to fix this in the current milestone, so I can't give you any expected release yet. It sounds like you have a workaround that gives you a usable proxy. What are your concerns with using it? Unless you're using the part of the service that reference DataSet I would say this is probably the best workaround.

One idea to help build confidence with the workaround would be to generate a proxy using a tool that targets .NET Framework (such as Add Service Reference or svcutil.exe) and compare the output. They should generate similar code, with this tool mostly attempting to filter out features that are unsupported on .NET Core. As long as you aren't using any features that aren't supported by WCF on .NET Core it's possible to use the file generated from svcutil.exe.

[markecw]

@StephenBonikowsky @dasetser Are you able to commit to a future release on this? It seems to me it should be a simple fix, and seems quite risky to leave unfixed as many may not realise their enums are wrong if used on a 3rd party service. As I do not know what other bugs could be caused by using the work around I can not ask to devote QA resources to it. Thanks Mark

[StephenBonikowsky]

@markecw When the current tooling update is completed we review our backlog of tooling issues and pull in issues that will be fixed in the next release. This issue will go into that backlog, we just can't promise it will or will not go into the next tooling update.

[ThomasPe]

Any news on this? no update for almost a year

[fbrum]

Hi all,

This problem also happens when using svcutil with /wrapper option. We are forced to use /wrapper option to create the specified properties for nullable properties, but doing so we lose the enum values

[DecimatorZA]

Hi all,

Any update on this?

I recently ran into the same issue as described by the OP. I have an enum WCF reference and instead of the enum's retaining their original values, they get assigned their index values.

Say we have an enum: ProdRoute = 33 and its 15th in the list of enums, when referenced the value is 14 and not 33.

This is causing our third party integrations to send through the incorrect data.

Any ETA on this issue?

[imcarolwang]

Hi @DecimatorZA, until a solution to this problem is available, you can try a workaround by applying [flags] attribute to the enum property.

[imcarolwang]

Current release of the tool has limited support of DataTable type serialization, more details: https://github.com/dotnet/wcf/issues/3712.

[softwareofsweden]

The problem is the XmlSerializer which doesn't handle the numeric values of the enumerations. By default the DataContractSerializer is used; but having DataSets members in any contracts, will force the XmlSerializer to be used instead.