Have a hosting package for Azure SQL that uses LocalDB during dev

[erikrenaud]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

To speed up startup (my laptop is 2 years old), instead of relying on the AddSqlServer Hosting package for SQL (which spins up a Microsoft SQL container), would a solution that uses LocalDB for local dev be interesting ?

I was able to achieve this :

IResourceBuilder<IResourceWithConnectionString> sql = default!;
if (builder.Environment.IsDevelopment())
{
  sql = builder.AddConnectionString("sql");
}
else
{
  var sqlServer = builder.AddSqlServer("sql").WithHealthCheck();
  var sqlData = sqlServer.AddDatabase("sqldata");
  sql = sqlServer;
}

var dataMigrator = builder.AddProject<Projects.Lanvac_Lanvantis_DataMigrator>("dataMigrator")
  .WithReference(sql);
if (sql is IResourceBuilder<SqlServerServerResource>) dataMigrator.WaitFor(sql);

At the same time, an integration package that does what the DataMigrator does (based on EF concepts)s would be awersome. Maybe seed data in a sql file in the AppHost project (seed.sql, seed.dev.sql, seed.production.sql) and somesort of mode to run the migrations (do nothing, Migrate, DropCreate, EmptyFill). I use a strategy like this that allows each EF Context to be in it's own schema.

Describe the solution you'd like

something like :

.addAzureSqlServerWithLocalDB("sql")

Additional context

No response

[davidfowl]

What would the localdb integration do other than set a connection string?

[erikrenaud]

What would the localdb integration do other than set a connection string?

Good question David - i've just reread the docs on how to publish to AzureSQL and maybe the experience is a bit different than i initially imagined:

var sqlServer = builder.AddSqlServer("sqlserver")
                       **.DevelopUsingSqlLocalDB()**
                       .PublishAsAzureSqlDatabase()
                       .AddDatabase("sqldb");

I agree that other than settings things up, it's quite anemic and only sets up the connection string. The good thing might be that the connection string is created in the code, so i don't have to include it in the AppHosts's appsettings.json. Also, there could be a check to ensure that LocalDB is installed. Finally, by having it uniform, it could benefit from the dependency stuff (i.e. WaitFor would work).

Since Aspire is opinionated though, i do believe the community could benefit from a official DataMigrator project based on EF migrations with standard stuff. i.e.

builder.AddDataMigration("dataMigrator")
           .AddContext<DataContext1>("sqldb1", "schemaForContext1")
           .AddContext<DataContext2>("sqldb1", "schemaForContext2")
           .AddContext<DataContext3>("sqldb2", "schemaForContext3")
           .PublishUsingMigrations() || PublishUsingEmptyFill()
           .DevelopUsingMigrationsAndDropCreateWhenIncompatible() || .DevelopUsingDropCreateWhenIncompatible()

I'd love to provide sample code for during a brainstorm as these ideas are how I have it setup for most of my projects done before using Aspire.

[davidfowl]

Maybe there's something there for localdb but I'm not really sure about the value. Feel free to spike something and come back to the issue with a prototype that we can iterate on to see if it makes sense.

As for the data migrator, I think that should be a separate issue. I do think there's more we can do here but referencing the dbcontext in the apphost IMO is not the right approach.

[joperezr]

[Triage] - @IEvangelist we talked about this on triage and this may be a good thing to fix via a doc.