Remove With methods that take a connection string

[eerhardt]

Instead, when connecting to an existing resource that the DevHost doesn't manage, the connection string should be passed to the .AddXXX method when defining the component. The the .WithXXX methods only take the component and optionally a connectionName.

For example, today we have:

    public static IDistributedApplicationComponentBuilder<T> WithRedis<T>(this IDistributedApplicationComponentBuilder<T> projectBuilder, IDistributedApplicationComponentBuilder<RedisContainerComponent> redisBuilder, string? connectionName = null)
        
    public static IDistributedApplicationComponentBuilder<T> WithRedis<T>(this IDistributedApplicationComponentBuilder<T> projectBuilder, string connectionName, string connectionString)

We just need the first method. And then the Add method:

    public static IDistributedApplicationComponentBuilder<RedisContainerComponent> AddRedisContainer(this IDistributedApplicationBuilder builder, string name, int? port = null)

Would get an overload for directly connecting to an existing Redis instance:

    public static IDistributedApplicationComponentBuilder<RedisContainerComponent> AddRedis(this IDistributedApplicationBuilder builder, string name, string connectionString)

One design decision: We could name this new method Use instead of Add. Ex. instead of builder.AddRedis("cache", "localhost:3679"), we could have builder.UseRedis("cache", "localhost:3679").

@DamianEdwards @davidfowl @mitchdenny

[mitchdenny]

I was going to suggest something like this. When I was looking at setting up manifest publishing I was considering that I would have to inject a placeholder Redis component (for example) to hold the connection string so that it could get emitted to manifest.

I think that this is a good suggestion.

[eerhardt]

One design decision: We could name this new method Use instead of Add. Ex. instead of builder.AddRedis("cache", "localhost:3679"), we could have builder.UseRedis("cache", "localhost:3679").

@davidfowl suggested offline that we stick with Add and not use Use.

I'll start working on this tomorrow after my current change is done.

[mitchdenny]

One question, we currently have AddRedisContainer(...) ... are you going to have the method named differently (i.e. AddRedis(...). I am wondering whether we should be considering renaming AddRedisContainer(...) to AddRedis(...) for consistency ... or perhaps have AddRedisConnection(...)?

[eerhardt]

We talked about this. We are purposefully going to leave AddRedisContainer using "container" in the name, as that indicates it is a container that gets spun up locally.

However, I don't think there was consensus on whether the new method would be AddRedis or AddRedisConnection. I think there are advantages either way. What I remember was that we would just use AddRedis(name, connectionString). But I could be convinced to name it AddRedisConnection if someone feels strongly.

[DamianEdwards]

I think one step at a time is fine, i.e. let's do this with the existing AddRedisContainer and AddRedis names and we can get a sense of how it feels for the spectrum of scenarios we discussed and whether further differentiation via something like AddRedisConnection is warranted.

[davidfowl]

I think we may eventually land on a single name but lets get to the end and make all of the consumption consistent (connection strings and names of resources). We're landing in a really good place here with respect to the pattern.

[mitchdenny]

I would prefer just having AddRedis(...) in the future since we can disambiguate adequately using overloads and it'll "just work". I agree that we can do this incrementally though once we get a sense of how it hangs together.