Issue with applying EF Core migrations at design time

[bancroftway]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

On non-aspire projects, I am used to creating and applying EF Core migrations using add-migration and update-database command in VS PMC. I am trying to do the same thing in the Aspire project, where even though the distributed app is not running, I am hoping that the database can be started just long enough to apply the migrations. I followed this article: https://khalidabuhakmeh.com/add-ef-core-migrations-to-dotnet-aspire-solutions

I added a DesignTimeDbContextFactory to my app host project and added a project reference to my project containing the dbcontext.

My add-migration command succeeded, but the 'update-database` command throws this error: "Property CliPath: The path to the DCP executable used for Aspire orchestration is required.; Property DashboardPath: The path to the Aspire Dashboard binaries is missing."

My DesignTimeDbContextFactory is noted below. Note that I am on .Net Aspire 9.3 version.

public sealed class DataContextDesignTimeFactory :IDesignTimeDbContextFactory<AppDbContext>
{
    private static DistributedApplication? _app;
    private static readonly object _lock = new object();

    public AppDbContext CreateDbContext(string[] args)
    {
        lock (_lock)
        {
            if (_app == null)
            {
                _app = CreateAndStartAspireApp(args);

                // Register cleanup
                AppDomain.CurrentDomain.ProcessExit += CleanupApp;
                Console.CancelKeyPress += (_, e) =>
                {
                    CleanupApp(null, EventArgs.Empty);
                    e.Cancel = false;
                };
            }
        }

        // Get connection string from the running Aspire app
        var connectionString = _app.Services.GetRequiredService<IConfiguration>()
            .GetConnectionString("appdb");

        if (string.IsNullOrEmpty(connectionString))
        {
            throw new InvalidOperationException("Could not retrieve 'appdb' connection string from Aspire application");
        }

        Console.WriteLine("Using Aspire-managed database for migrations.");

        var optionsBuilder = new DbContextOptionsBuilder<AppDbContext>();
        optionsBuilder.UseNpgsql(connectionString);

        return new AppDbContext(optionsBuilder.Options);
    }

    private static DistributedApplication CreateAndStartAspireApp(string[] args)
    {
        Console.WriteLine("Starting Aspire application for migrations...");

        var builder = DistributedApplication.CreateBuilder(new DistributedApplicationOptions
        {
            Args = args,
            DisableDashboard = true, // No need for dashboard during migrations
            AllowUnsecuredTransport = true, // Allow unsecured transport for migrations               
        });

        // Reduce logging noise during migrations
        builder.Services.Configure<LoggerFilterOptions>(options =>
        {
            options.MinLevel = LogLevel.Error;
        });

        // Add your database configuration exactly as in your main AppHost
        var dbServer = builder.AddPostgres("postgres")
            .WithLifetime(ContainerLifetime.Session) // Keep alive for the session
            .WithDataVolume(isReadOnly: false);

        var appDb = dbServer.AddDatabase("appdb");

        var app = builder.Build();

        // Start the application asynchronously
        var startTask = Task.Run(async () =>
        {
            try
            {
                await app.RunAsync();
            }
            catch (Exception ex)
            {
                Console.WriteLine($"\n Aspire application error: {ex.Message}");
            }
        });

        // Wait for the database to be available
        WaitForDatabase(app, timeoutMinutes: 3);

        Console.WriteLine("Aspire application started successfully.");
        return app;
    }

    private static void WaitForDatabase(DistributedApplication app, int timeoutMinutes = 3)
    {
        var timeout = TimeSpan.FromMinutes(timeoutMinutes);
        var sw = System.Diagnostics.Stopwatch.StartNew();

        Console.Write("Waiting for database");

        while (sw.Elapsed < timeout)
        {
            try
            {
                var config = app.Services.GetService<IConfiguration>();
                var connectionString = config?.GetConnectionString("appdb");

                if (!string.IsNullOrEmpty(connectionString))
                {
                    // Test the connection
                    using var connection = new Npgsql.NpgsqlConnection(connectionString);
                    connection.Open();
                    Console.WriteLine(" Ready!");
                    return;
                }
            }
            catch
            {
                // Continue waiting
            }

            Console.Write(".");
            Thread.Sleep(3000); // Check every 3 seconds
        }

        Console.WriteLine();
        throw new TimeoutException($"Database did not become available within {timeoutMinutes} minutes. Make sure Docker is running.");
    }

    private static void CleanupApp(object? sender, EventArgs e)
    {
        if (_app != null)
        {
            try
            {
                Console.WriteLine("Stopping Aspire application...");
                _app.StopAsync(TimeSpan.FromSeconds(10)).Wait(TimeSpan.FromSeconds(15));
                _app.Dispose();
                _app = null;
                Console.WriteLine("Aspire application stopped.");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Warning: Error during cleanup: {ex.Message}");
            }
        }
    }
}

Expected Behavior

No response

Steps To Reproduce

Add the DataContextDesignTimeFactory to the App Host, and add a project reference to the project containing dbcontext. In PMC, select the default project as the project containing dbcontext.

In PMC. issue commands add-migration test, and then update-database

Exceptions (if any)

Property CliPath: The path to the DCP executable used for Aspire orchestration is required.; Property DashboardPath: The path to the Aspire Dashboard binaries is missing.
...........................................................
Unable to create a 'DbContext' of type 'RuntimeType'. The exception 'Database did not become available within 3 minutes. Make sure Docker is running.' was thrown while attempting to create an instance. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728

.NET Version info

.NET SDK:
Version: 9.0.300
Commit: 15606fe0a8
Workload version: 9.0.300-manifests.af4147de
MSBuild version: 17.14.5+edd3bbf37

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.300\

.NET workloads installed:
[wasm-tools]
Installation Source: VS 17.14.36121.58
Manifest Version: 9.0.5/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\9.0.5\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.5
Architecture: x64
Commit: e36e4d1a8f

.NET SDKs installed:
9.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Anything else?

[davidfowl]

Why are you adding to the migrations to the app host project? They are supposed to be added to an application that references the dbcontext.

[bancroftway]

@davidfowl The migrations are not added to the app host project, they are in the project that references the dbcontext. The App host only has the DesignTimeDbContextFactory...to be able to start the app temporarily, apply the migrations and shutdown the app.

Is this approach (to apply migrations by temporarily starting the app) even possible to apply migrations this way? Or should I stick with the worker service approach to apply migrations when app starts up.

[davidfowl]

The app host should not have anything related to the DbContext including the DesignTimeDbContextFactory. You can't run dotnet ef migrate on the app host.

[SimonGeering]

Myself, and a couple of other devs I code with on hobby projects outside of work have also hit this issue.

A good explanation of the situation and the practical issues its causing for folks trying to adopt aspire for the first time is covered in this blog post.
https://juliocasal.com/blog/how-to-seed-data-with-ef-core-9-and-net-aspire

I understand that MS have been focused on build recently and will now be working towards the .net 10 Q4 release but IMHO this situation, for those following the recommended docs from MS on seeding DBs
https://learn.microsoft.com/en-us/dotnet/aspire/database/ef-core-migrations#create-the-migration-service

prevents the use of the recommended approach from the EF Core docs
https://learn.microsoft.com/en-us/ef/core/modeling/data-seeding

This might be a great opportunity for some cross team collaboration that would leave those of us trying to learn how to adopt the best approaches to EF in an aspire world in a bit better position. To be clear I am not certain this needs a code change to either EF or Aspire, although it could be solved with an overload or better detection of the fact migration is underway.

Rather if there is a recommended approach that would work around this then adding that to the already otherwise very thorough (and much improved in the last year) aspire docs would present a for more pleasant first experience for those starting out with aspire, for many of whom the connection of an app to a database and running a migration will be some of their first use cases.

Thanks for all the hard work on Aspire.

[davidfowl]

cc @SamMonoRT @AndriySvyryd @roji

[AndriySvyryd]

We actually have been working together with the Aspire team on the docs and any "recommended" approaches on EF docs is what we think would be best for the majority of the apps using EF (and currently most of them aren't using Aspire). But the recommendations in the Aspire docs effectively override EF docs as they are targeting a narrower scenario (perhaps this could be mentioned in the Aspire docs explicitly). Having said that, this particular interaction is already being tracked in dotnet/aspire-samples#401, the docs just haven't been updated yet because Aspire 9 uses EF 8 on .NET 8. Beginning with EF 10 we should be able to keep the documentation in-sync.