Azure Functions CLI - such a pretty logo for such an awesome functionality

How to access EF’s DbContext in an Azure Function on V2 runtime?

This post was most recently updated on November 14th, 2019.

Reading Time: 3 minutes.

This post describes how you can access your Entity Framework Core model classes and the database context in your Azure Functions. In my example I’m using EF Core 2.1, but the main principle should be the same for later versions as well. Please note, that I use Azure functions runtime 2.x (and so should you!)

Another easy one, that I was unable to find much guidance on!

But first, let’s start with the basics. Why would you want to have this setup? Why would you want to utilize your dbcontext class and Entity Framework Core models in an Azure function?

A few scenarios come to mind!

Why use DbContext in your Azure Functions?

I already had an ASP.NET Core MVC web application, which was using Entity Framework Core and SQL server. I wanted to add a scheduled task that would do some cleanup and analysis steps on the database – something non-urgent, but rather scheduled and running for maybe a few minutes at a time.

Additionally, these functions shouldn’t affect the actual web app’s execution and performance. So, a pretty good match for Azure Functions!

How to configure your Azure Functions to use EF’s DbContext?

Through some googling and a bit of trials and errors I came up with the following approach:

You’ll need to add these dependencies – and hence the NuGet packages “Microsoft.EntityFrameworkCore” and “Microsoft.EntityFrameworkCore.SqlServer“. See an example below:

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.SqlServer;

Intellisense won’t ever tell you that you need the package and the dependency to Microsoft.EntityFrameworkCore.SqlServer. In fact, the using directive will appear unused, and Intellisense will likely suggest you should remove it! But you will need it to connect to an SQL server with EF.

Visual Studio will prompt you to remove the dependency to SqlServer as it's "unnecessary". Don't remove it, though - you actually need it for the EF's DbContext to work in your Azure Functions!
Visual Studio will prompt you to remove the dependency to SqlServer as it’s “unnecessary”. Don’t remove it, though – you actually need it for the EF’s DbContext to work in your Azure Functions!

If you do, though, running the function will fail.

Note: If you’re using the latest version of the Azure Functions CLI (2.18.3 at the time of writing this), you won’t in fact need the dependency for Microsoft.EntityFrameworkCore.SqlServer.

Prerequisites taken care of, what does the actual function look like?

After a bit of back and forth, I came up with a fully functional setup, that lets my Azure Function to run on a trigger (web request – but this could also be a schedule!) and make changes to the db. However, it’s not deployed to production yet or anything – so don’t mistake it for a stable or battle-proven approach (yet)!

See below for my example:

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.SqlServer;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs.Extensions.Http;

namespace Koskila.Contoso.AzureFunctions
    public static class AssociatePages
        public static async Task Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
            string defaultConnection = Environment.GetEnvironmentVariable("DefaultConnection");
            var options = new DbContextOptionsBuilder();

            var h = new HttpContextAccessor() { HttpContext = req.HttpContext };
            var db = new ApplicationDbContext(options.Options, h);

            foreach (var p in db.YourEntities)
                // Do something cool here

            return new OkResult();

This piece of code should successfully connect to a MS Sql Database, and perform whatever cool stuff it needs to do!


The approach is thread-safe, as it’s using different instances of the database context in different modules of the application. That doesn’t mean you won’t run into issues though: You can, of course, still run into a deadlock and other concurrency issues if you’re not careful about what you’re developing, but that’s no different to any other application.

0 0 vote
Article Rating
Notify of
most voted
newest oldest
Inline Feedbacks
View all comments