Azure-functions-core-tools: Feature Request: app.config in azure functions

[shyamal890]

Currently we are utilizing local.settings.json for app settings when running the azure function app locally and it fetches settings from the app settings tab in azure portal when in production.

Problems with this approach:

1. How does a referenced assembly (data service) fetch connection strings, app settings from parent project in local testing and in production?

2. This would be addressed if azure functions fetches settings from web.config or app.config file.

3. Creates confusion as most .NET projects follow app.config and web.config. People have to informed that local.settings.json is just for testing in local environment and that referenced assembly won't look for settings in this file.

[mikhailshilkov]

json-based settings seem to be the new standard for .NET Core projects, so I guess functions just follow along that trend

[jeffhollan]

Yes would agree with @mikhailshilkov here - as far as I know #1 also works today and connection strings and app settings will correctly redirect to fetch from the right source. Have you hit any limitations where this doesn't work?

[maakku]

I think I hit a limitation, kinda, not exactly related to the problems mentioned above though. I implemented a wcf proxy for logic apps to call (wsdl had recursive reference in a message response schema -> couldn't use the SOAP connector). I wanted to add wcf message logging but couldn't find a way to do this in code, in app.config it would be easy.

[ahmelsayed]

tracked by https://github.com/Azure/azure-functions-host/issues/992

[grammophone]

I am afraid that the current approach easily doesn't work. When someone uses existing class libraries expecting to be setup using standard general configuration sections, for example something as common as the Unity dependency injection framework, and not just plain AppSettings or ConnectionString keys, Azure functions become the first .NET citizen breaking all of these in the ecosystem, because these libraries otherwise run successfully in console apps, WPF, ASP.NET, everywhere else. Thus, in my opinion, this decision constitutes a poor design move. If for some reason one thinks that a different way of setup is preferred, it should be an extra feature and not break what runs in all other environments.

I solved the problem of running my existing logic layer objects in Azure functions by delegating the work into a different AppDomain which has an App.config associated with it, and created the necessary cross-AppDomain communication. It should be simpler, though. This feature request is valid.

[manishsg]

I agree app.config approach should be supported by Azure functions..

[rlightner]

@grammophone Can you give a small example of this?

[grammophone]

Of course, @rlightner.

The contents of the ZIP file:

• In ITraceWriter interface, we abstract the TraceWriter.

• The MarshalledTraceWriter is an ITraceWriter implementation which can be marshalled by reference accross AppDomains.

• The IWorker is a disposable interface abstracting the work to take place. Its single method DoWork method takes an ITraceWriter argument. But you can define your own interface.

• The Worker is an abstract base implementation for IWorker which is marshallable by reference accross AppDomains. Subclass and override the DoWork method.
• The NopWorker is an example worker which logs that it does nothing.
• The WorkerProvider<IW> provides transparent proxies of objects running in a separate AppDomain and implementing a generic IW interface.
• Function1 is a demo Azure Function which uses a WorkerProvider<IWorker> to create a NopWorker running in a different AppDomain and calls the method DoWork on the proxied interface in order to successfully do nothing.

Add an App.Config to your project and remember to press F4 on it and set "Copy to Output Directory" to "Copy if newer". Good luck!

AzureFunctionToAppDomain.zip

[rlightner]

@grammophone Thank you kindly! Are you doing any type of DI in your created AppDomain?

[grammophone]

@rlightner you are welcome. Yes, the referenced libraries in my function use extensive DI based on Unity and defined in various .config files, included from the main .config of the running AppDomain:

This is just the same as including the configuration sections inline; the libraries make no distinction between inline and included sections.