C# extension methods are too limited for use in non-async code.

[koolraap]

The non-async methods generated in the C# FooBarExtensions.cs class are too limited for practical use.

1. Cannot access custom headers. We pass an X-Correlation-Id between services, we can't do this with these methods. Please expose the customHeaders parameter in extension methods.
2. Returning result.Body makes it impossible to retrieve the status code, which makes determining success or failure tricky, it also gimps our metric tracking.

public static FooBarModel GetDocument(this IFooBars operations, int? fooBarId)
{
    return Task.Factory.StartNew(s => ((IFooBars)s).GetDocumentAsync(fooBarId), operations, CancellationToken.None, TaskCreationOptions.None, TaskScheduler.Default).Unwrap().GetAwaiter().GetResult();
}

public static async Task<FooBarModel> GetDocumentAsync( this IFooBars operations, int? fooBarId, CancellationToken cancellationToken = default(CancellationToken))
{
    HttpOperationResponse<FooBarModel> result = await operations.GetDocumentWithHttpMessagesAsync(fooBarId, null, cancellationToken).ConfigureAwait(false);
    return result.Body;
}

[devigned]

@stankovski thoughts on this?

[koolraap]

The header/correlation-id thing can be worked around with something in the pipeline, but ultimately hiding any parameters makes sync code a second-class citizen to async code. Where I work we have 1% async code, most of our work is enhancements rather than greenfield. Moving to REST is a Big Thing, and that's partially repurposing existing sync code.

So, the question is, are you supporting sync code as a first class citizen?

[Nexusger]

@koolraap If I see it correctly, your issue 1 also applies to the Async method, am I right? You can't inject custom header there either. Which is a bummer.

We have the same problem. Currently moving to micro services, we need to create an ever increasing number of services and the code created by Autorest is quite useful for that. Yet we have to modify the code every time we create it (expose custom headers to sync- and async- methods, to include a correlation ID).

Maybe another command line flag could be used, so the backward compatibility is kept? Something like
`...

-ExposeCustomHeader: Exposes the custom header attribute in the generated methods.

...`

[stankovski]

I would recommend adding a flag in autorest for C# to allow specifying what sync wrappers should be generated -SyncWrappers None|Essential|All. This will also be useful for clients where .Unwrap().GetAwaiter().GetResult(); is undesirable.

[koolraap]

Thank you!