Open MikeStall opened 7 years ago
Suggest using the folder name bindings
or even bin\bindings
. As a stopgap, we could simply have the VS tooling copy the binaries to that folder if they are a custom binding.
Would really recommend taking the NuGet package approach only. This would give us a lot of flexibility when dealing with the assembly resolution issues we currently have with the temporary implementation, using the same mechanism as our NuGet resolution process, which allows for very controlled loading behavior based on the dependencies manifest (lock/deps). There are other benefits as well, mostly related to the load context used by the runtime.
This still enables file based deployment (without requiring publishing), but would just mean that what gets deployed is a package, as opposed to loose files. This also gives us consistent loading behavior between package referenced (e.g. from NuGet) and file based deployed binding extensions.
@fabiocav That makes a lot of sense. In my spec, I wrote that the CLI should do NuGet restore itself, but it sounds like you're recommending that we simply put all the functionality in Script Host. Is that accurate?
Yes. Need to flush out the actual details, the runtime doesn't have to be the one actually restoring things (it could) but it would use the restore artifacts to load the extensions.
Are there docs that describe how this works today, and any logging/debug hooks that might be useful?
I'm asking as I'm finding the current docs, such as the samples by @lindydonna, don't work for me on MacOS, with JS based Function apps running locally using func host start
, so it would be great to double check against the docs and contribute any feedback once I've spotted the issue.
Need to finalize how to load extensions into Runtime. Currently, it's via an appsetting that points to a directory, and we can scan the dir for files with "extension" in the name. That's a temporary mechanism.