ExecutionContext.FunctionDirectory should return the same location (Function directory), regardless of whether you're running a C# script or a class library. With the latest changes, precompiled libraries behave differently than those that use the new VS tooling model (where attributes are used directly).
This change regresses my popular CoderCards sample: https://github.com/Azure-Samples/functions-dotnet-codercards, which customers have forked and use in demos. Other PM samples are using this feature, which is a good indicator that customers are as well. It's not acceptable to have customers change their code just to use the final version of the tooling. While technically we can regress behavior because the tooling is in preview, this change is just asking for customer confusion and CRIs.
From a customer perspective, they expect the same behavior in a precompiled function with hand-authored function.json as a Visual Studio model with attributes. We've been telling customers that they behave identically, and the only difference is the tooling support.
@davidebbo suggested that the ExecutionContext add a FunctionAppDirectory property that would point at the root (where host.json lives). This makes sense to me as it would be much more useful in VS based scenarios.
I like that idea! We'd add this directory for all sceanrios, right?
Yes, these two properties would be present on ExecutionContext and behave the same way in all different development modes.
@davidebbo should we keep the consistent behavior for FunctionDirectory? That's the consensus of most of us :)
@lindydonna Yes, I just sent a short mail summary.
@davidebbo Thanks, just saw it!
Fixed.