-
Notifications
You must be signed in to change notification settings - Fork 449
Authoring & Testing Language Extensions
V2 only. This does not apply to V1.
Your langue worker needs to be in a directory named the same as the Language
property (i.e. "python"). Inside the directory there needs to be your worker.config.json
and the files needed to run your language worker
Example:
(root) (i.e. "C:\temp\workers")
| python
|| worker.config.json
|| worker.py
Your worker.config.json
is a file that tell the Functions host how to start your language worker
Example:
{
"Description":{
"Language":"python",
"Extension":".py",
"DefaultExecutablePath":"python",
"DefaultWorkerPath":"worker.py",
"Arguments":[]
}
}
It has two sections: Description
and Arguments
. It's important not to include any other settings than what is shown in the example.
Description has 4 arguments that are used to determine when to use your language worker and how to start it.
-
Language
: this is your language descriptor. It doesn't actually need to match the language (You could name your python worker "python-beta1"). All characters need to be lower case and the directory name also needs to be lower case. -
Extension
: this is the file extension your provider will be used for. (i.e. '.py' or '.test.py') -
DefaultExecutablePath
: this is the executable that will be invoked, generally it is found on thePATH
, but an absolute path can be used, if necessary (but probably shouldn't ship like that...) (i.e. "python" or "node") -
DefaultWorkerPath
: This is the entry point for your worker. It will be passed in as the first argument (i.e. "worker.py" gets passed in with a fully qualified path "python C:/temp/workers/python/worker.py")
Arguments is an array of strings that is can be used to specify additional arguments after the filename
To learn about how the worker should behave and initiate the gRPC connection, please refer to this document.
- dotnet 2.1.2
- whatever framework you're using on
PATH
(i.e. python) - download latest "Functions.Private.xxx.zip" from
dev
- your implementation of the language worker
- a sample Function App project to run
- Set your environment variables (either globally or in your terminal session)
-
AzureWebJobsScriptRoot
is the path to your Function App project (i.e. your sample code you're testing with) -
languageWorkers:workersDirectory
is the path to your workers directory for all the language workers (i.e. "C:\temp\workers" which contains your worker "C:\temp\workers\python", "C:\temp\workers\node") -
languageWorkers:language:workerDirectory
is the path to the specific language worker (i.e. "C:\temp\pythonWorker" which contains your worker.config.json file "C:\temp\pythonWorker\worker.config.json")
-
- start the host
- from the "Functions.Private..." directory you unzipped earlier, go to "SiteExtensions/Functions"
- dotnet .\Microsoft.Azure.WebJobs.Script.WebHost.dll
- Logs default to file system. To see them in stdout, set
AZURE_FUNCTIONS_ENVIRONMENT
toDevelopment
. - Prepend Language Worker Console logs with LanguageWorkerConsoleLog to differentiate user logs vs system logs. Any console logs wihtout LanguageWorkerConsoleLog prefix will be written to user logs only
- Functions Host logs (which will tell you if there was a problem with your config/etc.) are under
Host
folder - Language Worker logs are under
Worker
folder and yourLanguage
property in your config will determine the directory name - If you want full verbosity for the logs, be sure to use a
host.json
that looks something like:
{
"Logging": {
"LogLevel": {
"Default": "Debug"
}
}
}
- If you want full verbosity for the logs to console and files, add fileLoggingMode to
host.json
:
"logging": {
"LogLevel": {
"Default": "Debug"
},
"fileLoggingMode": "always"
}
On windows, logs are written to C:\Users\username\AppData\Local\Temp\Functions
- Configuration Settings
- function.json
- host.json
- host.json (v2)
- Http Functions
- Function Runtime Versioning
- Official Functions developers guide
- Host Health Monitor
- Managing Connections
- Renaming a Function
- Retrieving information about the currently running function
- Site Extension Resolution
- Linux Consumption Regions
- Using LinuxFxVersion for Linux Function apps
- Out-of-proc Cancellation Tokens
- Assembly Resolution in Azure Functions
- ILogger
- Precompiled functions
- Official Functions C# developer reference
- Contributor Onboarding
- Development Process
- Deploying the Functions runtime as a private site extension
- Authoring & Testing Language Extensions
- Bindings in out-of-proc
- Language Extensibility
- Worker Capabilities
- Investigating and reporting issues with timer triggered functions not firing
- Sharing Your Function App name privately
- Azure Functions CLI release notes [moved here]
- Function App Zipped Deployment [deprecated]