Joe*_*ner 14 c# azure-functions
我构建了一个Azure Function应用(v2)。所有功能所需的配置任务都在Setup类中完成,该类的结构如下:
[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>");
...
}
}
Run Code Online (Sandbox Code Playgroud)
在ConfigureServices我想从配置文件中读取连接字符串。为此,已使用来指定功能应用程序基本文件夹SetBasePath。但是我发现没有办法访问此路径。根据https://github.com/Azure/azure-functions-host/wiki/Retrieving-information-about-the-current-running-function的说明,ExecutionContext可以将一个函数注入其中,其中包含所需的路径。但我怎么访问ExecutionContext我的Startup课吗?
小智 16
您可以在启动文件中使用这段代码。我今天刚刚为我的项目测试了它,它适用于云和本地。
var executioncontextoptions = builder.Services.BuildServiceProvider()
.GetService<IOptions<ExecutionContextOptions>>().Value;
var currentDirectory = executioncontextoptions.AppDirectory;
Run Code Online (Sandbox Code Playgroud)
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));
}
}
}
Run Code Online (Sandbox Code Playgroud)
And your local.settings.json might look like this:
{
"IsEncrypted": false,
"Values": {
"KeystoneDB": "[CONNECTION STRING HERE]"
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
}
}
Run Code Online (Sandbox Code Playgroud)
You can also use Key Vault with Environment. It works great.
小智 -3
尝试使用Environment.CurrentDirectory
| 归档时间: |
|
| 查看次数: |
2482 次 |
| 最近记录: |