AddParameter(...)

[mitchdenny]

Fixes #1958

• AddParameter method
• Surrogate for connection strings (to give ParameterResource the IResourceWithConnectionStrings interface)
• Manifest writing
• AddConnectionString variant
• Docs
• Unit tests

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

Also delete WithReference(ConnectionString)

[mitchdenny]

Still a work in progress. Manifest does not presently generate correctly.

[mitchdenny]

@davidfowl latest PR does some fairly major stuff in terms of changing the way connection strings work so that a context variable is passed in as well as there being a global execution context (this is the beginning of avoiding having to interpret the --publisher switch.

I started pulling a thread here and this is where I've ended up. It might end up being too big and I need to back out of it but I think it is worth exploring still.

[davidfowl]

@davidfowl latest PR does some fairly major stuff in terms of changing the way connection strings work so that a context variable is passed in as well as there being a global execution context (this is the beginning of avoiding having to interpret the --publisher switch.

Why is that change required?

[mitchdenny]

Why is that change required?

Gather around for an epic tale :)

Why DistributedApplicationExecutionContext?

In the issue for this PR we have the following code:

var parameter = builder.AddParameter("myconnectionstring", secret: true);
var catalogdb = builder.Operation switch {
    Publish => builder.AddParameter("catalogdb", secret: true).AsConnectionString(),
    Run => builder.AddPostgres("postgres").AddDatabase("catalogdb")
};

var myapp = builder.AddProject<Projects.MyApp>("myapp");
                   .WithReference(catalogdb);

The DistributedApplicationExecutionContext is a type that exposes an enumeration DistributedApplicationOperation. It is my approach to builder.Operation in the code above. So, it will be builder.ExecutionContext.Operation instead. My thinking is that we'll need a contextual object in multiple places and may want to expose various methods/properties on it.

Rather than defining multiple properties on the builder which disappears after we start running the DistributedApplicationExecutionContext is exposed on the builder, but also injected into the DI container.

Why string? GetConnectionString() to void ApplyConnectionString(ConnectionStringCallbackContext context)?

Consider the following code:

var parameter = builder.AddParameter("myconnectionstring", secret: true);
var catalogdb = builder.Environment.EnvironmentName switch {
    "Production" => builder.AddConnectionString("catalogdb"),
    "" => builder.AddPostgres("postgres").AddDatabase("catalogdb")
};

var myapp = builder.AddProject<Projects.MyApp>("myapp");
                   .WithReference(catalogdb);

Here we are using environment name to switch between using connection strings or creating a database. This means that the manifest that is generated will produce two different results depending on the environment. Here is an example of the JSON for each environment (simplified for the sake of brevity):

For Production:

{
  "resources": {
    "catalogdb": {
      "type": "parameter.v0"
      "value": "{catalogdb.inputs.value}",
      "inputs": {
        "value": {
          "type": "string",
          "secret": true
        }
      }
    }
    "myapp": {
      "type": "project.v0"
      "env": {
        "ConnectionStrings_catalogdb": "{catalogdb.value}"
      }
    }
  }
}

For everything else:

{
  "resources": {
    "postgres": {
      "type": "postgres.server.v0"
    },
    "catalogdb": {
      "type": "postgres.database.v0",
      "parent": "postgres"
    }
    "myapp": {
      "type": "project.v0"
      "env": {
        "ConnectionStrings_catalogdb": "{catalogdb.connectionString}"
      }
    }
  }
}

The key issue is the difference in these two lines:

        "ConnectionStrings_catalogdb": "{catalogdb.value}"
        "ConnectionStrings_catalogdb": "{catalogdb.connectionString}"

In the code on main the resource types themselves don't emit the {catalogdb.connectionString} value. Instead it is the WithReference(...) for connection string resources that implement this type. When dealing with a parameter which has a connection string surrogate wrapped around it, using {catalogdb.connectionString} would be invalid.

We could put in some special case handling for the surrogate and not have to make these changes. But it also sounded like we might need to accommodate connection strings becoming connection properties - if we head down that path then we'll probably need to have some kind of context object arrangement like this. We may also need to go async to support provisioning scenario as well (not sure on that yet).

The way it works is that the ExecutionContext is exposed as a property on the ConnectionStringCallbackContext so these methods now have much greater access, they may also possibly be able to resolve services from DI, although we don't presently do that.

Current challenges

I'm currently looking at how the Azure provisioner works in context of all this but I think it'll work OK.

[mitchdenny]

... the other thing I am toying with is getting rid of the UseEmulator(...) calls for Azure Storage and Cosmos and instead making them the default behavior but that requires a deeper conversation.

[mitchdenny]

Reverted to an earlier commit. Exploration of this idea is on this branch where we can refer back to it if/when we want to tackle this issue:

https://github.com/dotnet/aspire/tree/mitchdenny/apply-connectionstring-exploration