Open DamianEdwards opened 8 months ago
There is no reason we couldn't hang these extensions off IDistributedApplicationBuilder?
The IDistributedApplicationTestingBuilder
interface doesn't expose IDistributedApplicationBuilder
so we'd need to expose it in both places explicitly.
We already have CreateResourceBuilder(...)
that does this on IDistributedApplicationBuilder
. Is this more about aligning these two method names across IDAB and IDATB?
We already implement CreateResourceBuilder(...)
in both places. The downside is that this would polute the intellisense interface for IDAB and IDATB.
Pollute in what way?
I take that back. I might be a huge fan of this idea ;) This might provide an elegant solution to this:
var builder = DistributedApplication.CreateBuilder(args);
var sql = builder.AddSqlServer("sql").PublishAsAzureSqlDatabase((resource, construct, sqlServer, databases) => {
sqlServer.AddOutput("someOutput", blah);
});
// Currently this doesn't work because sql is of type IResourceBuilder<SqlServerServerResource>.
var app = builder.AddProject<Projects.MyApp>("myapp")
.WithReference(sql.GetOutput("someOutput"));
// ... but with this API, this might be viable.
var app = builder.AddProject<Projects.MyApp>("myapp")
.WithReference(builder.GetAzureSql("sql").GetOutput("someOutput"));
This would be instead of doing something like this:
var sql = builder.AddSqlServer("sql").PublishAsAzureSqlDatabase(out var azureSql);
In the following test, notice the complicated line required to get an existing resource from the builder and modify it using the extension methods on the specific resource type:
This line:
We should consider adding extension methods to make it easy to get an
IResourceBuilder<TResource>
for an existing resource in a builder by the resource name. For example, for Redis:Then the line in the test above could become:
This has a nice symmetry with the
builder.AddRedis("cache")
call in the AppHost project'sProgram.cs
that added the resource.One challenge will be that if we want these methods to be on
IDistributedApplicationTestingBuilder
, they would need to exist in new packages for each resource type, as we recently split all the hosting resources into their own packages. So e.g. for Redis we'd need anAspire.Hosting.Testing.Redis
package that depends onAspire.Hosting.Redis
andAspire.Hosting.Testing
, and then the test project would need to depend on that.