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

Serializing extension types (Request) #824

Closed
psalmnoelff opened this issue Feb 15, 2022 · 4 comments
Closed

Serializing extension types (Request) #824

psalmnoelff opened this issue Feb 15, 2022 · 4 comments
Labels

Comments

@psalmnoelff
Copy link

psalmnoelff commented Feb 15, 2022

So i have some methods that read a request object, which all have base models. (like from issue #206 )

public class Animal
    {
        public Guid RequestId { get; set; }
        public string AnimalCenter { get; set; }
    }
  public class Cat : Animal
    {
        public string Name { get; set; }
    }

    public class Dog : Animal
    {
        public string Name { get; set; }
    }

On my service definition:

[ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        ResponseClass1 GetCat(Cat catRequest);

        [OperationContract]
        ResponseClass1 GetDog(Dog dogRequest);

    }

However when the wsdl is generated, it seems to render all properties into a single class, and it does not serialize the extension types (as per issue #209 ).

Is there a flag that we need to enable this? Or should this by default work?

@psalmnoelff
Copy link
Author

Hi! Just a gentle nudge. I noticed that using DataSerializer, this works by default. Is there a way we can implement this using XMLSerializer?

@andersjonsson
Copy link
Collaborator

If you look at the changes included in PR #209, support was only added to MetaWCFBodyWriter (the one used with DataContractSerializer).
If you feel like submitting a PR I think you could copy most of those changes from MetaWCFBodyWriter to MetaBodyWriter. Hopefully the structure is similar enough.

Those two classes could probably share much more of the code than they do today...

@github-actions
Copy link

github-actions bot commented Apr 9, 2022

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Apr 9, 2022
@github-actions
Copy link

This issue was closed because it has been inactive for 14 days since being marked as stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants