When running Entity Framework Core (EF Core) design-time commands like update-database or add-migration in an ASP.NET Core application, you might occasionally encounter a confusing log output:

Plaintext

[11:27:52 FTL] Application terminated unexpectedly
Microsoft.Extensions.Hosting.HostAbortedException: The host was aborted.

Accompanied by warnings regarding table sharing:

Plaintext

[11:27:53 WRN] The entity type 'BusinessAddress' is an optional dependent using table sharing without any required non shared property...

Although your database update often finishes successfully, seeing fatal or unexpected termination logs during a simple migration can be alarming. This guide explores why this behavior occurs and how to clean up your Program.cs and entity configurations to resolve it.

1. Understanding the Root Cause

Why Does HostAbortedException Happen?

To find your DbContext configuration, EF Core design-time tools must inspect your application's service container. They do this by temporarily bootstrapping your ASP.NET Core application via Program.cs.

Once EF Core extracts the configuration it needs, it intentionally signals the host to abort/stop. The hosting infrastructure throws a HostAbortedException to handle this graceful shutdown. If your application wraps builder.Build() or app.Run() in a generic try-catch logging block (frequently used with Serilog or NLog), it catches this expected design-time abort and logs it as a fatal application crash.

Why Do Table-Sharing Warnings Occur?

Warnings regarding entities like BusinessAddress, BusinessInformation, and FbrTokenSetting happen because these entities are configured for table sharing (mapping multiple entity types to the same database table). If all their properties are nullable, EF Core cannot determine at runtime whether the dependent record actually exists in the database when querying.

2. Fixing the HostAbortedException Log Noise in Program.cs

If you are using a global exception handler or logger wrapper around your host startup, you need to explicitly ignore HostAbortedException so it isn't logged as a fatal application failure.

Update the exception catch block in your Program.cs file:

C#

using Microsoft.Extensions.Hosting;

try
{
    var builder = WebApplication.CreateBuilder(args);

    // Add your services, controllers, and database contexts here...
    
    var app = builder.Build();

    // Configure your middleware pipeline...

    app.Run();
}
catch (Exception ex) when (ex is not HostAbortedException)
{
    // Log fatal errors only if it's NOT an EF Core design-time host abortion
    Log.Fatal(ex, "Application terminated unexpectedly.");
}
finally
{
    Log.CloseAndFlush();
}

By filtering out HostAbortedException, your logs will remain clean during design-time tasks while continuing to catch real runtime failures.

3. Resolving the Table-Sharing Warnings

To resolve the warnings about optional dependent entities using table sharing, you have two primary options:

Option A: Add a Required Property

Ensure that your dependent entity (e.g., BusinessAddress) contains at least one required property or foreign key that guarantees its existence can be tracked.

Option B: Configure the Relationship as Required in DbContext

If the dependent table should always exist alongside its principal entity, explicitly configure the relationship in your DbContext using OnModelCreating:

C#

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    modelBuilder.Entity<CompanyPrincipalEntity>()
        .HasOne(p => p.BusinessAddress)
        .WithOne()
        .HasForeignKey<BusinessAddress>(b => b.Id)
        .IsRequired(); // Marks the relationship as required to satisfy table sharing rules
}

Conclusion

By updating your Program.cs try-catch block to ignore HostAbortedException and properly defining your table-sharing relationships, you protect your build pipeline from unnecessary error noise. Your migrations will execute cleanly, keeping your development workflows smooth and predictable.