Add extensiblity article on how to write a non container based custom resource

[davidfowl]

As an example:

https://anthonysimmon.com/referencing-external-docker-containers-dotnet-aspire-custom-resources/

It should show how to use lifecycle hooks, the ResourceNotificationService, and the ResourceLoggerService to push updates to the dashboard.

cc @asimmon @mitchdenny

---

Associated WorkItem - 442938

[mitchdenny]

This article should cover, or link to some kind of meta conversation around whether it makes sense to write a custom resource which is not container based.

Consider Aspire as it exists today, all of our resources are either container based, cloud-based (with or without emulators) or core resource types such as parameters.

In many cases a custom resource which is not a container could quite possibly be a very thin wrapper around AddParameter and AddConnectionString. In the article we would need to articulate the reason why someone would want to go to the extra effort to build a custom resource type.

For example, lets say you were calling an Internet hosted API that you couldn't replicate locally. That would really just be a URL and potentially some kind of API key.

@davidfowl can you give an example of a custom resource that is not:

a) something that you would NOT run locally in a container.
b) something that requires the features of dashboard updates
c) something that wouldn't be just as easily served by AddConnectionString()

[davidfowl]

My aspire YARP resource that runs in process!:

https://github.com/davidfowl/AspireYarp

[davidfowl]

The resource linked in the article above shows logs from the running container which makes it better than using AddConnectionString IMO.

[davidfowl]

Another example are the Azure and AWS resources.

[asimmon]

If this can help, at Workleap we've been using custom resources in three ways:

1. To host YARP (similar to, but not exactly like, https://github.com/davidfowl/AspireYarp)
2. To host a minimal API that forwards the developer's local Azure CLI credentials to any container that uses Azure Identity with RBAC-protected resources (similar to what we distributed as a Docker image)
3. Expose long-lived Docker containers that are managed by Docker Compose

[IEvangelist]

@davidfowl - I like it, want me to put something together based on the YARP example or just create one that add the SmtpClient like with the MailDev example, but shows how to do so as a component?

[davidfowl]

@IEvangelist This is low priority at the moment. We have more important stuff to document 😄. Lets let this sit for a bit.

The main thing we'd want to show here is usage of IDistribuedApplicationLifecycleHook, ResourceLoggerService and ResoruceNotificationService.