Skip to content

Authoring & Testing Language Extensions

Pragna Gopa edited this page Dec 9, 2018 · 18 revisions

V2 only. This does not apply to V1.

Authoring config driven language provider


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


(root) (i.e. "C:\temp\workers")
| python
|| worker.config.json


Your worker.config.json is a file that tell the Functions host how to start your language worker




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 '')
  • DefaultExecutablePath: this is the executable that will be invoked, generally it is found on the PATH, 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. "" gets passed in with a fully qualified path "python C:/temp/workers/python/")

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 "" 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 to Development.
  • 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 Workerfolder and your Language 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

Clone this wiki locally
You can’t perform that action at this time.