Get root directory of Azure Function App v2

Question

I build an Azure Function App (v2). Configuration tasks necessary for all functions are done in a Setup class that is structured like the following:

[assembly: WebJobsStartup(typeof(Startup))]

internal class Startup : IWebJobsStartup
{
  public void Configure(IWebJobsBuilder builder)
  {
    Configuration = new ConfigurationBuilder()
                      .SetBasePath(<functionAppDirectory>)
                      .AddJsonFile("local.settings.json")
                      .Build();
    builder.AddDependencyInjection(ConfigureServices);  
  }

  public IConfiguration Configuration { get; set; }

  private void ConfigureServices(IServiceCollection services)
  {
    var connection = Configuration.GetConnectionString("<myconnection-string>");
    ...
  }
}

In ConfigureServices I want to read a connection string from a configuration file. For that the function app base folder has be specified with SetBasePath. But I found no way to get access to this path. According to https://github.com/Azure/azure-functions-host/wiki/Retrieving-information-about-the-currently-running-function an ExecutionContext can be injected in a function, which contains the path need. But how do I access ExecutionContext in my Startup class?

Answer 1

You can use this piece of code in your startup file. I have just tested it today for my project and it works on both cloud and local.

var executioncontextoptions = builder.Services.BuildServiceProvider()
    .GetService<IOptions<ExecutionContextOptions>>().Value;
var currentDirectory = executioncontextoptions.AppDirectory;

Answer 2

TL;DR: just use Environment.GetEnvironmentVariable.

The ConfigurationBuilder approach shows up in a lot of blog posts, and worked up until we started doing DI. But there is no context parameter, so ConfigurationBuilder immediately starts to cause some strain.

I think people went this direction because in Azure Functions 2, we switched to ASP.NET Core configuration which caused ConfigurationManager to stop working. ConfigurationBuilder was a reasonable place to land. It felt congruent with MVC, and worked fine up until the introduction of DI.

But now that we are doing DI, it's becoming clear that Environment.GetEnvironmentVariable might have been the better choice all along for this platform... There's less code overhead, and it maps cleanly to the configuration model of Azure Functions: in dev, it picks up items in the local.settings.json > Values array, and in production it picks up your environment variables, and it just works.

It is different than what we do in MVC. Until these platforms come into closer parity, however, we should do what makes sense in Functions, rather than trying to force solutions from MVC.

So:

[assembly: WebJobsStartup(typeof(StartUp))]
namespace Keystone.AzureFunctions
{

    public class StartUp : IWebJobsStartup
    {
        public void Configure(IWebJobsBuilder builder)
        {           
            var connectionString = Environment.GetEnvironmentVariable("KeystoneDB");

            // Configure EF
            builder.Services.AddDbContext<KeystoneDB>(options => options.UseSqlServer(connectionString));
        }
    }
}

And your local.settings.json might look like this:

{
    "IsEncrypted": false,
    "Values": {
        "KeystoneDB": "[CONNECTION STRING HERE]"
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

You can also use Key Vault with Environment. It works great.

Answer 3

Greeting,
I found a solution that works in the Startup :

var fileInfo = new FileInfo(Assembly.GetExecutingAssembly().Location);
string path = fileInfo.Directory.Parent.FullName;
var configuration = new ConfigurationBuilder()
    .SetBasePath(Environment.CurrentDirectory)
    .SetBasePath(path)
    .AddJsonFile("appsettings.json", false)
    .Build();