C#•2y ago

How to block the execution of a method when running EF migration

Hello,
I have a background service registered in Program.cs. It does an HTTP call to an external service that is essential for getting some configuration settings.
This HTTP call should not happen when

ef

ef

commands are executed, so I was wondering what solutions might be there.

Zendist•6/3/24, 7:37 PM

What is calling these EF commands? The BG Service or the HTTP server?

tera•6/3/24, 8:09 PM

just run migrations before you even start the background service

Jimmacle•6/3/24, 9:38 PM

running migrations while your app is running at all sounds like a bad idea, i run them at startup

CoreOP•6/4/24, 3:39 AM

The background service is an . I also create an instance of that just to do a http call, but all of this happens once.

When I run the EF command it also executes the HTTP call. The app is not running when the migration is being created

CoreOP•6/4/24, 3:42 AM

For the app that external service call is essential, but it also gets executed whenever I create a migration. I think that is because the app is built one time before the EF command

CoreOP•6/4/24, 3:57 AM

Jimmacle•6/4/24, 5:16 AM

when you run a migration your app is run up until its services are configured and you build the host

Jimmacle•6/4/24, 5:16 AM

so if you're actually making external calls when you're supposed to just be configuring services it will cause problems

Jimmacle•6/4/24, 5:21 AM

if that's unavoidable then your only option is to set up an IDesignTimeDbContextFactory afaik https://learn.microsoft.com/en-us/ef/core/cli/dbcontext-creation?tabs=dotnet-core-cli

Design-time DbContext Creation - EF Core

Strategies for creating a design-time DbContext with Entity Framework Core

CoreOP•6/4/24, 8:29 PM

Sorry, my notifications were turned off. Thank you, I will look into this as soon as I can

CoreOP•6/11/24, 9:05 AM

@Jimmacle it's been a while. I iplemented the IDesignTimeDbContext, but the outcome is the same. The HTTP call is still executed.

CoreOP•6/11/24, 9:19 AM

Sorry, it turns out that is no longer supported in .NET 6 and above. I found a discussion on GitHub about it

Jimmacle•6/11/24, 2:11 PM

where did you read that?

Jimmacle•6/11/24, 2:11 PM

i'm using it in .NET 8 with no problems

tera•6/11/24, 2:26 PM

yeah same

Jimmacle•6/11/24, 2:29 PM

it's also still in the EF core documentation that i linked above

JJimmacle it's also still in the EF core documentation that i linked above

CoreOP•6/12/24, 1:25 PM

Yes, and that is what I implemented. My output shows that the DesignTimeFactory was executed and not the regular DbContext

CoreOP•6/12/24, 1:28 PM

I found a solution which is available from .NET 7. EF exposes a static flag trough . I simply organized the

Program.cs

Program.cs

content in a way to only have code needed for EF in design time.

CCore Yes, and that is what I implemented. My output shows that the DesignTimeFactory ...

tera•6/12/24, 3:11 PM

that should not happen if you are doing everything right

how/from where (exact command, directory) are you running migrations
where is the dbcontextfactory located (project..)
is it same project as the dbcontext

tera•6/12/24, 3:11 PM

my suspicion is that it was not even using that factory you made

CCore I found a solution which is available from .NET 7. EF exposes a static flag trou...

tera•6/12/24, 3:16 PM

i would rather focus on solving the actual problem than workaround

Ttera my suspicion is that it was not even using that factory you made

CoreOP•6/12/24, 3:52 PM

It was, I did a Console.Write in the factory

Ttera that should not happen if you are doing everything right - how/from where (exact...

CoreOP•6/12/24, 3:55 PM

It was located in the main project, not in which the dbcontext. But either way, it should work from the main project, because for EF commands both the source project and the other project where the dbcontext is located should be specified