.NET 9 aspire no migrations were applied on Azure Container Environment

[BarFoo]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a worker service project as part of my .NET 9 aspire solution that is responsible for handling new database migrations with EF core and PostgreSQL.

This works fine on local development, however when deploying to production with new migrations, on Azure no migrations take place and the output is always as follows:

No migrations were applied. The database is already up to date.

There are no database connection issues. The production environment uses Postgres Flexible Server with supplied username and password parameters.

Expected Behavior

For migrations to be recognised and the database updated.

Steps To Reproduce

No response

Exceptions (if any)

No exceptions. No errors with the code. Just migrations not being recognised in ACE environment.

.NET Version info

.NET 9

Anything else?

No response

[davidfowl]

Adding @AndriySvyryd for migration debugging tips.

[AndriySvyryd]

Could you provide more information on how are migrations applied? Also, what is the project structure, where is your DbContext and migrations? It might also help to turn up the logging verbosity (for DbLoggerCategory.Migrations category).

[BarFoo]

Thanks for your responses @davidfowl and @AndriySvyryd and my apologies for not providing further detail earlier.

The migration service is really simple. Now I think about it, perhaps too simple? Although the reason for this simplicity is that in .NET 9 invoking MigrationAsync checks and ensures the database exists, and in a migrations compatible context.

Here is the code for the worker service.

using Microsoft.EntityFrameworkCore;
using App.Data.Contexts;
using Npgsql;
namespace App.MigrationService;

public class MigrationWorker : BackgroundService
{
    private readonly IServiceProvider _serviceProvider;
    private readonly IHostApplicationLifetime _hostApplicationLifetime;
    private readonly ILogger<MigrationWorker> _logger;

    public Worker(IServiceProvider serviceProvider,  
               IHostApplicationLifetime hostApplicationLifetime,
               ILogger<MigrationWorker> logger)
    {
        _serviceProvider = serviceProvider;
        _hostApplicationLifetime = hostApplicationLifetime;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken cancellationToken)
    {
        try
        {
              using (var scope = _serviceProvider.CreateScope())
              {
                  var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

                  await context.Database.MigrateAsync(cancellationToken);
              }
        }
        catch (Exception ex)
        {
            _logger.LogCritical(ex);
            throw;
        }
        finally
        {
            // Stop the worker service after migrations
            _hostApplicationLifetime.StopApplication();
        }
    }
}

The database context and entities are in a .Data class library project.

The registration in app host is also pretty simple:

var builder = DistributedApplication.CreateBuilder(args);

var username = builder.AddParameter("username", secret: true);
var password = builder.AddParameter("password", secret: true);

var postgres = builder.AddAzurePostgresFlexibleServer("postgres").WithPasswordAuthentication(username, password);

var db = postgres.AddDatabase("postgresdb");

var migrations = builder.AddProject<Projects.MigrationService>("migration-service")
    .WithReference(db)
    .WaitFor(db);

builder.Build().Run();

Thanks

[AndriySvyryd]

Apart from increasing logging verbosity I'd suggest verifying that the connection string the service gets in ACE is the expected one and matches the one in the app.

[BarFoo]

I've checked the connection string and it matches.

I will inrease logging verbosity as soon as I can and keep you updated. Thanks.

[dotnet-policy-service]

This submission has been automatically marked as stale because it has been marked as requiring author action but has not had any activity for 14 days.
It will be closed if no further activity occurs within 7 days of this comment.