Variance on a method returning ContainerResource or ProjectResource

[Falco20019]

I am currently just playing around with the idea to have an extension returning either the project (for env=development) or a deployed version of some (for env=production).

AddContainer returns an IResourceBuilder<ContainerResource> whereas the AddProject returns a IResourceBuilder<ProjectResource>.

Both share a lot of interfaces like IResource, IResourceWithEnvironment, IResourceWithEndpoints.

Is there some way using generics to have a method that returns IResourceBuilder<T> that offers all common interfaces (maybe through constraints or added types/interfaces)? I didn't find any besides returning IResourceBuilder<IResource> and using pattern matching to upcast again, cluttering the code as chaining won't work as nicely.

It might also be possible to write a class that wraps it using constrains, but then I again don't know how to call it as I would need to pass it a type that's part of the inheritance chain.

The idea is that the references between them, stuff like environment variables or endpoints are still the same, no matter the environment.

[jrunestone]

I've also run into this and have had the same observation/reflection when setting defaults for my resources automatically. I usually need a resource object with two or more interfaces mentioned. Right now we have to pattern match for ProjectResource, ContainerResource, etc and duplicate code for them.

Basically I want if (resource is (IResourceWithEndpoints, IResourceWithEnvironment) res) :)

[davidfowl]

C# 25 maybe 😬

[Falco20019]

Thanks @davidfowl, I take this as "not supported by the language" instead of "you just missed some easy to use variance feature" 😁

I really thought I've just overlooked something I could apply to a method that hints the return value to be promised to contain those interfaces on the generic type. Like on the input type. But I assume due to limited scoping, it's a lot easier to have on inputs than on outputs.

[KennethHoff]

The closest you can get is something like:

IResourceBuilder<T> DoThing<T>(IResourceBuilder<T> builder) where T: IResourceWithEndpoints, IResourceWithEnvironment;

[Falco20019]

@KennethHoff Thats what I did, but sadly this would only work to ensure the input parameter is already implementing those interfaces and passing through the original type. In my case, I would create the objects inside and therefore wouldn't be able to choose the <T> at the caller side as there is no type that that would match. Also stuff like creating my own interface that inherits all and casting the objects with Unsafe.As was not working and resulted in runtime errors (EntryPointNotFoundException). I assume due to ordering/mapping problems in the virtual table.

The only other options I could come up were either using IDynamicInterfaceCastable (too cumbersome) or creating a wrapper class for the resource that implements all interfaces and another wrapper for the IResourceBuilder to forward all calls to the original one or the wrapped resource.

[Falco20019]

I was able to find a light-weight solution that doesn't crash. Just in case someone else has a similar need.

internal interface IProjectOrContainerResource : IResourceWithEnvironment, IResourceWithArgs, IResourceWithEndpoints, IResourceWithWaitSupport, IComputeResource;
internal class ProjectOrContainerResourceBuilder<T>(IResourceBuilder<T> builder) : IResourceBuilder<IProjectOrContainerResource>
    where T : IResourceWithEnvironment, IResourceWithArgs, IResourceWithEndpoints, IResourceWithWaitSupport, IComputeResource
{
    private IResourceBuilder<T> _builder = builder;

    public IResourceBuilder<IProjectOrContainerResource> WithAnnotation<TAnnotation>(
        TAnnotation annotation,
        ResourceAnnotationMutationBehavior behavior = ResourceAnnotationMutationBehavior.Append) where TAnnotation : IResourceAnnotation
    {
        _builder = _builder.WithAnnotation(annotation, behavior);
        return this;
    }

    public IDistributedApplicationBuilder ApplicationBuilder => _builder.ApplicationBuilder;

    public IProjectOrContainerResource Resource => Unsafe.As<IProjectOrContainerResource>(_builder.Resource);
}

This can then be used like new ProjectOrContainerResourceBuilder<ContainerResource>(builder.AddContainer(...)) or new ProjectOrContainerResourceBuilder<ProjectResource>(builder.AddProject<TProject>(...)). Both can be assigned to a variable of type IResourceBuilder<IProjectOrContainerResource> while keeping the original resource with all its traits. The only limitation is, that IContainerFilesDestinationResource and IResourceWithServiceDiscovery from ProjectResource would be unknown but could still be handled using builder.Resource is IResourceWithServiceDiscovery. As those are not adding any members, it would also work to just add them to the interface and type constraint, but this is the IMO safer way to ensure type safety and the intentions of Aspire.

Still not sure why directly using Unsafe.As<IResourceBuilder<IProjectOrContainerResource>>(builder.Add...) throws EntryPointNotFoundException while Unsafe.As<IProjectOrContainerResource>(_builder.Resource) works fine, but I assume it's related to the nested generics.

Sadly it's not possible to also inherit IResourceBuilder<T> as this will lead to CS0695 on compilation. This would have simplified the usage to builder is IResourceBuilder<IResourceWithServiceDiscovery>.

[Falco20019]

/CC @jrunestone as this at least covers the ones you need.

[jrunestone]

Thanks for the tip but I'd rather not use unsafe type casting :D

I'm iterating the resource collection and casting to ProjectResource, ContainerResource, ExecutableResource instead. Less code, more readable. At least @davidfowl has seen this so now we wait for some aggregate interfaces or something ;)