annotation and context standards

[The3G]

There are a number of sealed classes that represent the context; these are passed to developers code via a annotation callback function; both the callback func of the annotation and context passed are inconsistent and differ between each implementation.

The context naming of the IServiceProperty accessor flips between ServiceProvider or Services; with the callback having no constraint or defined common/generic pattern; some passing.

It would be I feel good to have some consistency and or have a minimum requirment enforced by an interface/generic on the callback func and the context these contracts would ease the development and implementation of annotations and allow for code reuse.

[davidfowl]

cc @eerhardt feedback for our API cleanup.

[eerhardt]

@The3G - do you have some concrete examples?

[The3G]

@eerhardt just one area are the event objects, they have a mixture property names for the IServiceProvider 'Services' and 'ServiceProvider'

It would be good IMHO if a event base class was used to hold common properties like IServiceProvider; and thus providing a consistent common interface or extending the IDistributedApplicationResourceEvent interface, better yet have a generic of DistributedApplicationResourceEvent that implements the IDistributedApplicationResourceEvent with the IServiceProvider as a property.

I've also seen this mixture of public property naming within the Annontations and Callbacks thus far.

[eerhardt]

FYI @mitchdenny

[mitchdenny]

The reason IDistributedApplicationResourceEvent doesn't expose IServiceProvider as a property is because sometimes events can fire before the service provider exists. That's why it is up to each individual event to expose it if it has access to it when it is typically fired.

That said most events should expose it and if the property name is not consistent we should address that.

We could define another interface to test for whether an event exposes the service provider but I'd be interested in the scenario that requires it since when you subscribe to events you do it for each event type.

[The3G]

@mitchdenny Thanks for your response; I understand that dependent on when the event is fired that the IServiceProvider may be not availible; I would however thought that a IServiceProvider property still exist with either a null or empty IServiceProvider.

If the IDistributedApplicationResourceEvent was to updated with a IServiceProvider? [propertyName] (the chosen consistant name) or a new interface of IDistributedApplicationResourceEventWithServiceProvider (for example) with the IServiceProvider? property, together with a helper that checks the event support the IServiceProvider and has a value present this would help for the follow.

the creation a single function/callback that handles all/any current events or any new events that we may need to created to support different use cases and/or events from different runtime/deployment platforms.

[The3G]

/*: the callback for the IDistributedApplication.Eventing.Subscribe, 
 *: differs from the callback events on the resource, even though the content of the 
 *: event has a T resource property already. */
async Task DistributedApplicationResourceEventHandler<T>(
    T resource,
    IDistributedApplicationResourceEvent @event,
    CancellationToken @token)
where T : class
{
    /*: we have to do this because the IDistributedApplicationResourceEvent 
     *: doesn't declare a property for the IServiceProvider in it's interface. */
    var eventType = @event.GetType();
    var eventProperty = eventType.GetProperties()
        .FirstOrDefault(p=>
            (p.Name == "Services" || p.Name == "ServiceProvider")
                && 
            p.PropertyType == typeof(IServiceProvider)
        );
    var serviceProvider = eventType.GetProperty(eventProperty.Name)?
        .GetValue(@event) as IServiceProvider ?? null;

    var logger = serviceProvider.GetRequiredService<ILogger<ResourceEvent>>();
    logger.LogInformation($"resource: {resource.GetType().Name} event: {@event.GetType().Name}");


    await Task.CompletedTask;
}

[davidfowl]

So you want IDistributedApplicationResourceEvent to have a Services property so you can write polymorphic code over it.

[The3G]

the same would apply for other properties on the event/annotation/context objects/callbacks if/when the values can/are null. i.e. the eventing, logging and notification services.

[davidfowl]

I don’t think so, but if you can show exactly what you are trying to build , it will help motivate the work

[The3G]

I don’t think so, but if you can show exactly what you are trying to build , it will help motivate the work

@davidfowl the development is purely conceptual at present, but the idea of the team is to have a number of generic hooks into the aspire runtime events and contexts with regards not notification of other on-premises or cloud services for a hybrid/multi-cloud application without the needs to configure complex VLAN or change corporate firewalls during the development phase.

The hooks would be used to allow other services to be triggered and/or trigger/report dashboard messages/state updates.

For example we have a number of distributed application at present (not aspire) that use on-premise, azure and amazon services. We are looking to use aspire to enable developers (initally manually, none aspire deployment) to perform runtime hybrid/multi-notifications to the dashboard and other services.

[davidfowl]

It's a bit too abstract to made any concrete changes on our end. When you build and run into issues, share the code and scenarios and we'll be able to design something.

[davidfowl]

Did a scan:

Type	Property	Notes
BeforeStartEvent	Services
AfterPublishEvent	Services
BeforePublishEvent	Services
DeployingContext	Services
PublishingContext	Services
InitializeResourceEvent	Services
ResourceEndpointsAllocatedEvent	Services
ResourceReadyEvent	Services
ConnectionStringAvailableEvent	Services
DistributedApplication	Services
BackchannelConnectedEvent	Services
BackchannelReadyEvent	Services
AfterResourcesCreatedEvent	Services
AfterEndpointsAllocatedEvent	Services
BeforeResourceStartedEvent	Services
DistributedApplicationExecutionContext	ServiceProvider
DistributedApplicationExecutionContextOptions	ServiceProvider	Nullable
HttpCommandRequestContext	ServiceProvider	required init
HttpCommandResultContext	ServiceProvider	required init
ContainerFileSystemCallbackContext	ServiceProvider	required init
UpdateCommandStateContext	ServiceProvider	required init
ExecuteCommandContext	ServiceProvider	required init
InputsDialogValidationContext	ServiceProvider	required init

We have some things with ServiceProvider and others with Services

[KennethHoff]

I personally think ServiceProvider is a more descriptive name.

Surprised nothing is called ApplicationServices though; I feel like I've seen that, but perhaps not.