[Feature Request] Provision for insertion of custom derived type in GetDerivedTypes in PolymorphicJsonConverter

[DheerendraRathor]

Issue:
Currently during deserialization of polymorphic classes, PolymorphicJsonConverter looks for derived types in SDK level assembly only. This hinders conversion to other derived classes implemented by customer outside SDK assembly.

Requirement:
In one of our cases, customers have liberty to create their own derived classes from a generic class (part of SDK assembly) with discriminator field and send request to service. This will work fine during serialization phase but during deserialization object of generic class will be returned which cannot be type casted to derived class.

// assembly: microsoft.azure.management.recoveryservices.backup

// Discriminator field petType
public partial class Pet 
{
  public string Name {get; set;}
  public string Color {get; set;}
}

public partial class Cat : Pet
{
  public bool IsCrookshanks {get; set;}
}

// In RecoveryServicesBackupClient.cs
DeserializationSettings.Converters.Add(new PolymorphicDeserializeJsonConverter<Pet>("petType"));

//==================================
// In client code outside sdk assembly

public partial class Mouse : Pet
{
  public bool IsPeterPettigrew {get; set;}
}

Here deserialization of {"name": "Tom", "petType": "Cat", "color": "grey", "isCrookshanks": false} of will return concrete object of type Cat but deserialization of {"name": "Jerry", "petType": "Mouse", "color": "grey", "isPeterPettigrew": false} will return object of type Pet which cannot be type casted to mouse.

Here on service side we are not interested in any Pet other than Cat but we are providing clients to add their own Pets if required.

Possible Solutions:

1. Currently autorest is looking for derived classes in the assembly of baseType. https://github.com/Azure/azure-sdk-for-net/blob/psSdkJson6/src/SdkCommon/ClientRuntime/ClientRuntime/Serialization/PolymorphicJsonConverter.cs#L33
   This can be changed to look into all loaded assemblies in current app domain via AppDomain.CurrentDomain.GetAssemblies()
2. A static method GetCustomKnownTypes can be implemented in all models which will return a list of known types and list can be filled by client code outside sdk assembly. Then GetCustomKnownTypes can be invoked during GetDerivedTypes method using reflections and then deserialization can be handled normally.

[shahabhijeet]

@DheerendraRathor just so that I understand what you are proposing.
Are you saying, get list of all loaded assemblies, regardless of managed/native and then check for types from those assemblies that are in list?
Or is there a way to filter out assemblies before start fishing for custom types?
And finally should we add this heuristics when we cannot find the derived type? (what should be the trigger to go this route, as this will have perf implications)
The part that is unclear is, how will the customer fill the new derived type list? What is that mechanism to know I need to find CustomKnownTypes?

[pakrym]

Hi. We're closing this issue as no response or updates have been provided in a timely. If you have more details and are encountering this issue please add a new reply and re-open the issue.