Ancestor classes without properties

The Autorest tool seems to have a limitation when it comes to ancestor classes with zero properties. This is causing issues for our API architecture:

        [HttpGet]
        [ActionName("ListJobs")]
        [SupportedGroupVersion("2016-05-01,2016-06-01")]
        [SwaggerResponseRemoveDefaults]
        [SwaggerResponse(
            HttpStatusCode.OK, 
            "Lists all the jobs in your Recovery Services Vault according to the query filters " + 
                "and the pagination parameters.", 
            typeof(ResourceList<JobBase>))]
        public HttpResponseMessage ListJobs(string resourceId)

And the models are defined thus:

We have an empty base to support requirements in the future which might not be met by the derived class – Jobin the middle. The SDK clients will be creating the specific derived objects (AzureIaaSVMJobor MabJob) based on the JobTypefield which also acts as the polymorphic discriminator. We cannot take a dependency on the C# Object(base of all objects) as this would break the contract at the service.

This will be a blocking issue for our SDK release where we need to generate the code for September release. Please let us know when this can be fixed in the autorest tool so that I can validate it.

[matthchr]

I am not on the core AutoRest team (so please do not take anything I say as officially from them), but as a C# developer I am not sure I understand the point of the JobBase class… how would it help me as a client? It has no properties so if something didn’t fit into the Job class then what could I do with the base class? As you’ve draw the diagram here, JobBase is basically an alias for C# Object – a class with no properties or methods on it (and it seems no abstract methods as well?)

I don’t get the point of it – can you outline a scenario where such a thing is actually helpful? Specifically I am interested in this case:

We have an empty base to support requirements in the future which might not be met by the derived class

If and when such a requirement comes, will the base class get properties (for the new requirement?) If yes, why not just wait until the requirement comes to add the base class (and until then just have Job inherit from object)?

[fearthecowboy]

This doesn’t seem to be a blocker for anyone at this point. The next c# generator may have an option for this.