How does EF core tools find my DbContext from my application to generate migration etc

Question

I asked copilot this question, about how EF Core Tool loads my app dll and execute DI service registrations, including builder.Services.AddDbContext(..), then getting my DbContext from DI. In Minimal API program.

It answers this:

Got it — you’re asking about the behind-the-scenes magic of how EF Core CLI commands (like dotnet ef migrations add) are able to get your DbContext from a .NET 10 minimal API project, even though you never explicitly “give” it to them.

Here’s the short, clear breakdown:

1. EF Core tools load your compiled app assembly When you run a CLI command, EF Core tools:

• Build your project (unless you pass --no-build).
• Load your app’s main assembly (your .dll) into a separate process.
• Look for an entry point — in minimal APIs, that’s the generated Program class with a Main method.

2. They use IDesignTimeDbContextFactory or CreateHostBuilder / WebApplication.CreateBuilder EF Core tries to create your DbContext in this order:

1. IDesignTimeDbContextFactory<T> — if you’ve implemented it, EF Core calls it directly.
2. CreateHostBuilder — for older ASP.NET Core patterns.
3. Minimal API bootstrap — for .NET 6+ minimal APIs, EF Core uses reflection to:
   • Call WebApplication.CreateBuilder()
     • Run your service registration code (so builder.Services.AddDbContext<...>() executes).
       • Build the IServiceProvider from the DI container.

3. Resolving your DbContext from DI Once the DI container is built, EF Core simply does:

Csharp
Copy code
var

This works because your DbContext was registered in Program.cs via AddDbContext.

4. Why it works without running your full app EF Core doesn’t actually start your web server — it only runs enough of your startup code to:

• Configure services
• Build the DI container
• Resolve the DbContext

It avoids calling app.Run() so your API doesn’t start listening on ports.

✅ In short: Yes — EF Core tools do load your app’s DLL, find the generated Program class, run your service registration code, and then pull your DbContext from the DI container. They rely heavily on reflection and conventions to make this work without you having to write special code.

If you want, I can draw you a step-by-step flow diagram of exactly how EF Core CLI spins up your minimal API just enough to get the DbContext. Would you like me to do that?Got it — you’re asking about the behind-the-scenes magic of how EF Core CLI commands (like dotnet ef migrations add) are able to get your DbContext from a .NET 10 minimal API project, even though you never explicitly “give” it to them.

Here’s the short, clear breakdown:

1. EF Core tools load your compiled app assembly
When you run a CLI command, EF Core tools:

• Build your project (unless you pass --no-build).
• Load your app’s main assembly (your .dll) into a separate process.
• Look for an entry point — in minimal APIs, that’s the generated Program class with a Main method.

2. They use IDesignTimeDbContextFactory or CreateHostBuilder / WebApplication.CreateBuilder
EF Core tries to create your DbContext in this order:

1. IDesignTimeDbContextFactory<T> — if you’ve implemented it, EF Core calls it directly.
2. CreateHostBuilder — for older ASP.NET Core patterns.
3. Minimal API bootstrap — for .NET 6+ minimal APIs, EF Core uses reflection to:
   • Call WebApplication.CreateBuilder()
     • Run your service registration code (so builder.Services.AddDbContext<...>() executes).
       • Build the IServiceProvider from the DI container.

3. Resolving your DbContext from DI
Once the DI container is built, EF Core simply does:

Csharp
Copy code
var

This works because your DbContext was registered in Program.cs via AddDbContext.

4. Why it works without running your full app
EF Core doesn’t actually start your web server — it only runs enough of your startup code to:

• Configure services
• Build the DI container
• Resolve the DbContext

It avoids calling app.Run() so your API doesn’t start listening on ports.

✅ In short:
Yes — EF Core tools do load your app’s DLL, find the generated Program class, run your service registration code, and then pull your DbContext from the DI container. They rely heavily on reflection and conventions to make this work without you having to write special code.

But what I want to understand is what it means to run enough of my startup code? It uses reflection to find my entry point, but how it knows to run enough code to build my DI?

Answer 1

I finally found out how this is achieved in ef core. Not only in efcore, we can also use the same instrumentation in our own libraries too. So here is how it works.

1. Actually AppServiceProviderFactory internally calls Microsoft.Extensions.Hosting.HostFactoryResolver.ResolveServiceProviderFactory(appEntryPointAssembly).
2. HostFactoryResolver just calls the entry point assembly's entry point method, which is Program.Main method. Even in minimal api, this method is synthesized by the compiler. But before calling the entry point method, it does this clever instrumentation or plumbing. It subscribes to the DiagnosticListener.AllListeners.Subscribe(observer).
3. Ok, so now it doesn't matter how we structure our code, because internally, Microsoft.Extensions.Hosting.HostBuilder uses DiagnosticSource to emit various events about what it is doing. So apparently, there are 2 important events, "HostBuilding", "HostBuilt", which we need. So when HostBuilder emits those 2 events, I mean they do it like, DiagnosticSource.Write("HostBuilt", ..) which synchronously calls the subscribed listeners (which is very important for this instrumentation to work), and our previous observer in step 2) will now see the event, say "HostBuilt", and it throws HostAbortedException which stops Program.Main to end without going further, just after the host was built. Observer will capture the IHost implementation built inside the OnNext observer method.
4. So here it's we now have fully built IHost object, we can its services.

I hope this helps anyone who is also interested how this works under the hood.

Answer 2

When EF Core tools run commands like dotnet ef migrations add, they perform a series of steps to load your application's main assembly and resolve the DbContext. Here’s how they determine what it means to run enough of your startup code to build the Dependency Injection (DI) container:

1. Loading the Assembly: The EF Core tools first build your project (unless you specify --no-build) and then load the compiled application assembly (your .dll) into a separate process.
2. Finding the Entry Point: The tools look for the entry point in your application, which in the case of minimal APIs is the generated Program class containing the Main method.
3. Executing Service Registration Code: To build the DI container, EF Core tools utilize reflection to call WebApplication.CreateBuilder(). This method is responsible for setting up the application and running the service registration code you’ve defined, such as builder.Services.AddDbContext<...>(). This is how EF Core knows to execute your service registration logic.
4. Building the DI Container: After executing the service registration code, the tools build the IServiceProvider from the DI container. This allows EF Core to resolve the DbContext you registered.
5. Avoiding Full Application Startup: Importantly, EF Core does not execute the entire application startup process (like starting the web server). It only runs the necessary parts of your startup code to configure services and build the DI container, avoiding the call to app.Run(), which would start listening for HTTP requests.

In summary, EF Core tools rely on reflection to find and execute just enough of your startup code to configure services and build the DI container, allowing them to resolve your DbContext without running the full application.

Answer 3

Thanks for reaching out!
EF Core CLI commands are designed to locate and create your DbContext even in minimal API projects where you don’t explicitly expose a startup class.EF Core CLI loads your built DLL, finds the generated Program class, creates a WebApplicationBuilder, runs your service registration code, builds the DI container, and resolves your DbContext from it.

Points can be considered for the issue
1.EF Core tools load your compiled application assembly when you run any EF command.

• Builds your project
• Loads your application’s main assembly (.dll) into a separate process.
• Locates the entry point in minimal APIs, this is the generated Program class with a main method.

2. EF Core discovers how to create your DbContext.

• IDesignTimeDbContextFactory<TContext> If your project implements this interface, EF Core uses it.
• CreateHostBuilder if present, EF Core invokes it.

3. EF Core resolves your DbContext from DI

Once the DI container is built, EF Core simply requests the service:

var context = provider.GetRequiredService<YourDbContext>();

This works because your DbContext was already added using:

builder.Services.AddDbContext<YourDbContext>(...);

4.EF Core does NOT run your full application

EF Core does not call app.Run() your web server does not start.