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?

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
    {
        [FunctionName("ContosoFunction")]
        public static async Task<iactionresult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            string defaultConnection = Environment.GetEnvironmentVariable("DefaultConnection");
            var options = new DbContextOptionsBuilder<applicationdbcontext>();
            options.UseSqlServer(defaultConnection);
 
            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!

Considerations

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.

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.
mm

Leave a Reply

avatar
5000
  Subscribe  
Notify of