Overview

To enable extensions to register additional functions which are not captured by the existing methods (scanning for methods with a valid trigger attribute via source gen or msbuild task).

Use Cases

Functions from extensions

Some extensions may want to expose function metadata definitions in their own way. For example, to support class-based orchestrators and activities in Durable Functions, the extension could provide functions metadata which all point to the same implementation which shims to the target class to invoke.

Primary vs Auxiliary

Today we assume there is only 1 instance of IFunctionMetadataProvider. This is both in how we consume it (importing a single instance) and in our setup logic: DefaultFunctionMetadataProvider is only registered if no other instance exists. We will need a solve both of these issues. To accomplish this, we first need to define two types of providers: primary and auxiliary. There should be only ever 1 instance of a primary provider. This provider should be responsible for registering all traditional functions: methods which include the function attribute and a valid trigger. The primary provider should index all assemblies loaded by the application. Auxiliary providers are then everything else: providers which register functions that fall outside of the primary providers scope (see durable example in use cases).

In this design, the DefaultFunctionMetadataProvider is 'primary', and will only register if no other primary provider is present. The source generator provider will also be 'primary'.

Concerns

We need to be careful about breaking changes with this design, as we do not want to regress the fallback behavior of default vs source-gen provider, nor impact any cardinality dependency injection assumptions for this service.