Skip to content
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

Closed
lmagyar opened this issue Jul 22, 2013 · 6 comments
Closed

svcutil compatibility and minor bugs #23

lmagyar opened this issue Jul 22, 2013 · 6 comments

Comments

@lmagyar
Copy link

lmagyar commented Jul 22, 2013

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.

@esskar
Copy link
Owner

esskar commented Jul 22, 2013

thanks for that, i will have a look into that asap

@lmagyar
Copy link
Author

lmagyar commented Jul 22, 2013

I mixed the word DataContract and DataMember in the description above, corrected it now.

@esskar
Copy link
Owner

esskar commented Jul 22, 2013

does this help?

@lmagyar
Copy link
Author

lmagyar commented Jul 23, 2013

I've added 2 commits.
The first keeps backward compatibility with current servers with ConditionalExpressionNode.Test "short name" T or C.
The second adds support to write sg like node.ToExpression<Func<...>>(new CustomContext()); currently this requires cast or extra typing with custom ConvertToExpression function.
(This is my first contribution to open projects, I'm a newbie on GitHub, I hope I did eg correctly.)

@lmagyar
Copy link
Author

lmagyar commented Jul 23, 2013

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.

@esskar
Copy link
Owner

esskar commented Jul 23, 2013

well, you need to trigger a pull request

esskar pushed a commit that referenced this issue Jul 23, 2013
commits related to svcutil compatibility and minor bugs (#23)
@esskar esskar closed this as completed Jul 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants