Remove ConnectionString on With methods in Hosting App Model

[eerhardt]

Instead, add new Add overloads that take a connection string to an existing server.

Note - I needed to make IDistributedApplicationComponentBuilder<out T> an out generic because I need IDistributedApplicationComponentBuilder<PostgresContainerComponent> to also be an IDistributedApplicationComponentBuilder<IPostgresComponent>.

Fix #62

[mitchdenny]

Because this redis component is being created based on a connection string we need to adjust the manifest writing for components created like this to include a connection string attribute. It should look like this:

{
  "components": {
    "<name>": {
      "type": "redis.v1",
      "connectionString": "<connection string>"
    }
  }
}

[eerhardt]

ok, I can make that change. I am a little concerned how the deployment tool is going to decide if this is the real connection string to use, or if it should provision a new one.

I think the main scenario is that the dev wants to use this specific connection string at dev time, but wants something different at publish time.

cc @ellismg - in case you have thoughts.

[davidfowl]

I think it's fine for this to be ambiguous for now. We have this problem with other environment variables as well.

[ellismg]

So my thinking here is that if the connectionString property is present on a redis.v1 component, we respect it, when you have another component that does a reference like this:

            "env": {
                "ConnectionStrings__redis": "{redis.connectionString}"
            },

And if connectionString is not present in this object in the manifest, then we use the value that would be injected by ACA and their connected services stuff?

Does that make sense? Using the existance of this key in the object to distinguish between "a literal" vs "something that needs to be resolved by the underlying platform"?

[eerhardt]

@davidfowl - maybe this is where the "DevHost" configuration stuff we talked about this week comes in. The DevHost code would have something like:

builder.AddRedis("cache", builder.Configuration.GetConnectionString("redisConnection"));

And then in DevHost\appsettings.Development.json (or user secrets):

{
  "ConnectionStrings": {
    "redisConnection": "localhost:6379"
  }
}

So when you F5 / dotnet run locally, you get a connection to localhost:6379.

Then at "manifest" generation time, you don't define ConnectionStrings:redisConnection, which means the above will return null, and that will mean "I want a new resource created for me for this".

[mitchdenny]

This looks good. I'm not sure about GetConnectionString(...) but given where we are right now it's probably the best option.

[mitchdenny]

Approved pending comment around manifest generation.