-
-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
svcutil compatibility and minor bugs #23
Comments
thanks for that, i will have a look into that asap |
I mixed the word DataContract and DataMember in the description above, corrected it now. |
does this help? |
I've added 2 commits. |
I've reverted the first st#pid commit, there is no need to keep backward compatibility, there is no way to send/accept these DataMember(Name = "T") values. Excuse me. |
well, you need to trigger a pull request |
commits related to svcutil compatibility and minor bugs (#23)
First, thank you for this great library! It's really terrific!!!
In ConditionalExpressionNode.cs the attribute
[DataMember(EmitDefaultValue = false, Name = "T")] on property
public ExpressionNode Test { get; set; }
conflicts with the same attribute on property ExpressionNode.Type.
Eg. ...Name = "C" as "Condition" could be a solution.
In PropertyInfoNodes.cs there is a
if SERIALIZE_LINQ_WITH_LONG_DATA_NAMES
instead of
if !SERIALIZE_LINQ_OPTIMIZE_SIZE
WARNING: Modifying it breaks backward compatibility with current services, DataContract name changes from "PI" to "PropertyInfoNode"!!!
The "long" DataContract names of MemberNode<> and ExpressionNode<> abstract generic classes should be specified, because svcutil generates "funny" names like ExpressionNodeOfLambdaExpressionQsd8_SODT. And recreates these abstract classes as non-abstract classes during proxy generation (metadata doesn't support abstract). Even when specifying the reference to Serialize.Linq.dll. With "long" DataContract name specified, only one useless non-abstract class should be deleted from the generated proxy.
Eg. [DataContract(Name = "MemberNodeGeneric")] and [DataContract(Name = "ExpressionNodeGeneric")] could be a solution.
The text was updated successfully, but these errors were encountered: