I am currently having trouble to debug my Azure Functions Core Tools in VS Code.
I am using the npm package azure-functions-core-tools#2.
As i read on many resources func host start / func start should always start the node process in with --inspect=9229. As you can see this is not the case in my setup:
[4/30/19 4:51:25 AM] Starting language worker process:node "/usr/lib/node_modules/azure-functions-core-tools/bin/workers/node/dist/src/nodejsWorker.js" --host 127.0.0.1 --port 50426 --workerId 3e909143-72a3-4779-99c7-376ab3aba92b --requestId 656a9413-e705-4db8-b09f-da44fb1f991d --grpcMaxMessageLength 134217728
[4/30/19 4:51:25 AM] node process with Id=92 started
[4/30/19 4:51:25 AM] Generating 1 job function(s)
[...]
[4/30/19 4:51:25 AM] Job host started
Hosting environment: Production
Also all attempts of changing the hosting environment failed. I tried to add FUNCTIONS_CORETOOLS_ENVIRONMENT to my local configuration, resulting in an error:
An item with the same key has already been added. Key: FUNCTIONS_CORETOOLS_ENVIRONMENT
I tried to add several environment variables in my launch and task settings, using --debug, changing project settings. Nothing works.
I am currently running this on the Windows Subsystem for Linux (WSL) and except this it works really well.
Anyone has a clue on what i am doing wrong here?
I don't think debug is enabled by default. You will have to set the language worker arguments for this to work as documented.
In local.settings.json
To debug locally, add "languageWorkers:node:arguments": "--inspect=5858" under Values in your local.settings.json file and attach a debugger to port 5858.
With func CLI
You could set this by using the --language-worker argument
func host start --language-worker -- --inspect=5858
In VS Code
If you are developing using VS Code and the Azure Functions extension, the --inspect is added automatically as the corresponding environment variable is set in .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "runFunctionsHost",
"type": "shell",
"command": "func host start",
"isBackground": true,
"presentation": {
"reveal": "always"
},
"problemMatcher": "$func-watch",
"options": {
"env": {
"languageWorkers__node__arguments": "--inspect=5858"
}
},
"dependsOn": "installExtensions"
},
{
"label": "installExtensions",
"command": "func extensions install",
"type": "shell",
"presentation": {
"reveal": "always"
}
}
]
}
You could also set this environment variable directly if you'd like instead of adding it in local.settings.json too.
Related
I'm trying to figure out how to use AWS toolkit for vscode. I go to the AWS extension and click Create New SAM Application, point to project directory and it creates a hello world function. Above it, it says Add Debug Configuration. I click that, choose nodejs 12.x and save the launch.json, but I don't get the run option. It still says Add Debug Configuration for some reason. How can I run my lambda functions locally in the console?
The launch.json file generates, but I can never run the code.
launch.json
{
"configurations": [
{
"type": "aws-sam",
"request": "direct-invoke",
"name": "new test:app.lambdaHandler (nodejs12.x)",
"invokeTarget": {
"target": "code",
"projectRoot": "new test/hello-world",
"lambdaHandler": "app.lambdaHandler"
},
"lambda": {
"runtime": "nodejs12.x",
"payload": {},
"environmentVariables": {}
}
}
]
}
I also tried navigating to the hello-world directory in terminal and executing node app.js, but it doesn't return anything
What am I doing wrong? I appreciate the help!
Make sure you have SAM CLI install in local, here are the instructions for installation https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html
Then run the command sam local start-api.
You should be able to access the api at http://127.0.0.1:3000/hello
You can also do the same via vscode by selecting Run > Run without debugging (shortcut: ctrl + F5)
I have Node JS Azure function that when I run locally needs the NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable needs setting for my code to work. This is because I am connecting to an emulated Cosmos DB running locally on my machine which require Node to allow for self signed certificates.
I only want this environment variable setting when I run locally as in production I will be using a real (i.e. non emulated) Cosmos DB instance. Rather than putting and #if debug in my code (or the equivalent for a Node Azure Function) I'd like my VS Code project to set the env var when it is launched.
I've trying following this answers advice but when VS Code launches the program the environment variable is not set as I get a runtime error in my code about self signed certificates not being authorised. My launch.json looks like this:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to Node Functions",
"type": "node",
"request": "attach",
"port": 9229,
"preLaunchTask": "func: ",
},
],
"environment": [{
"name": "NODE_TLS_REJECT_UNAUTHORIZED",
"value": "0"
}],
}
If I set the env var directly in code using process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0 everything is fine. I don't know how I can get VS Code to set this, or if it is even possible.
Please update
"environment": [{
"name": "NODE_TLS_REJECT_UNAUTHORIZED",
"value": "0"
}],
To Be
"env": {
"name": "NODE_TLS_REJECT_UNAUTHORIZED",
"value": "0"
},
Also please check the alternatives.
You can Update package.json scripts to add all environment variables on start like "runLocal": "NODE_TLS_REJECT_UNAUTHORIZED=0 ... your start code " or You can use third party lib called dotenv
this is how it works
01- Create .env file
02- Write all your environment variables key=val NODE_TLS_REJECT_UNAUTHORIZED=0
03- Update package.json scripts to add "runLocal": "NODE_ENV=dev ... your start code "
04- Check if node NODE_ENV is equal dev then load the dotenv
05- Import module in case of node env is local and call config function require('dotenv').config()
I have two questions on .net core applications for functions. I am using blobtrigger.
1) When I run my project locally I get this 'Hosting environment' on the command prompt console, I want to understand where is this variable set and how can I change it to development. Its misleading since I am only developing locally.
[5/23/2019 7:00:20 PM] Host started (773ms)
[5/23/2019 7:00:20 PM] Job host started
Hosting environment: Production
Content root path: C:Myproject\bin\Debug\netcoreapp2.1
Now listening on: http://0.0.0.0:7071
2) What is the difference between host.json and local.settings.json. When can host.json be used? So far I have only used local.settings.json and when I publish to azure I am creating configurations mentioned in local.settings.json but Host.json is not used it looks like. Whats the purpose of host.json file is.
"Hosting environment" on the console comes from the environment variable ASPNETCORE_ENVIRONMENT. When this variable is not set, it defaults to "Production".
It's set here: HostingEnvironment.cs
The reason behind this default is described in this github issue.
This variable is popular in dotnet core web apps, but it is not mentioned in official docs in Azure functions (I am not sure why). If you write a for loop and output all the environment variables to console from within a function, you will find that this variable is not set by default - neither in production, nor when running in Visual Studio.
If you wish to define this variable locally, you have a few different ways.
Setting the environment variable via command line:
setx ASPNETCORE_ENVIRONMENT "Development"
Defining this in Properties\launchSettings.json:
"commandName": "Project",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
Defining this in local.settings.json:
"Values": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
Note that this variable is not automatically defined to production when you publish your app to azure. You will have to define this variable in "Configuration" -> "Application Settings" in Azure portal.
In azure functions there appears to be another similar environment variable called AZURE_FUNCTIONS_ENVIRONMENT. This one is defined by default locally.
AZURE_FUNCTIONS_ENVIRONMENT = Development
This is not defined in production by default, and can be defined in the azure portal.
Difference between host.json and local.settings.json:
host.json is to configure pre-defined settings that function app infrastructure understands. It applies to both local and production environments. It doesn't allow custom settings though. local.settings.json on the other hand is useful for defining custom settings. host.json is committed into source control, but local.settings.json is usually left out of source control, and is considered to be a good location to store secrets and connection strings for development.
More details here about the differences: https://learn.microsoft.com/en-us/azure/azure-functions/functions-develop-vs#create-an-azure-functions-project (scroll to the end of that section)
host.json reference
local.settings.json reference
You can add "ASPNETCORE_ENVIRONMENT": "Development" in the local.settings.json, to change the hosting environment:
As you know, local.settings.json is just for local testing and will not be published to azure portal. For host.json(which will be published to azure), you can configure settings like loglevel(if you want to log) in azure portal. More details, please refer to this article of host.json.
Sometimes, most times, Microsoft has strange ways of doing things... we as the community have to either find a way around them, or conform. Well, if you are one of those who cant survive the idea to conforming to something that doesn't make sense, here is a solution:
Delete local.settings.json
Create two files (or many, each for your environment), and name them {environment}.local.settings.json eg: development.local.settings.json and production.local.settings.json
Create a task to copy your current environment file to local.settings.json
Here we go again: we got to duplicate tasks...
[
{
"label": "use development.local.settings.json",
"command": "cp development.local.settings.json local.settings.json",
"type": "shell",
"options": {
"cwd": "${workspaceFolder}/..."
}
},
{
"label": "use production.local.settings.json",
"command": "cp production.local.settings.json local.settings.json",
"type": "shell",
"options": {
"cwd": "${workspaceFolder}/..."
}
},
{
"label": "azure-func-development",
"type": "func",
"dependsOn": [
"use development.local.settings.json",
"build"
],
"dependsOrder": "sequence",
"options": {
"cwd": "${workspaceFolder}/.../bin/Debug/netcoreapp2.2"
},
"command": "host start",
"isBackground": true,
"problemMatcher": "$func-watch"
},
{
"label": "azure-func-production",
"type": "func",
"dependsOn": [
"use production.local.settings.json",
"build"
],
"dependsOrder": "sequence",
"options": {
"cwd": "${workspaceFolder}/.../bin/Debug/netcoreapp2.2"
},
"command": "host start",
"isBackground": true,
"problemMatcher": "$func-watch"
}
]
Don't get tired, we are not finished duplicating, yet...
Lets duplicate the launch.json configurations:
[
{
"name": "[Development] Attach to Azure .NET Functions",
"type": "coreclr",
"request": "attach",
"preLaunchTask": "azure-func-development",
"processId": "${command:azureFunctions.pickProcess}"
},
{
"name": "[Production] Attach to Azure .NET Functions",
"type": "coreclr",
"request": "attach",
"preLaunchTask": "azure-func-production",
"processId": "${command:azureFunctions.pickProcess}"
}
]
TL; DR
On Microsoft VSCode v1.6.1, how to:
Properly set runtime executable?
Properly pass Heroku arguments?
Run Heroku Node.js app?
Debug Heroku Node.js app?
Details
I have created a Heroku Node.js application, which is launched using the CLI command:
heroku local web
and successfully starts at port 5000.
I am trying to debug it using Microsoft Visual Studio Code, using the following launch.json configuration:
{
"name": "Launch",
"type": "node",
"request": "launch",
"program": "${workspaceRoot}/app.js",
"stopOnEntry": false,
"args": [],
"cwd": "${workspaceRoot}",
"preLaunchTask": null,
"runtimeExecutable": "/usr/local/bin/heroku",
"runtimeArgs": [
"local web",
],
"env": {
"NODE_ENV": "development"
},
"console": "internalConsole",
"sourceMaps": false,
"outFiles": []
}
But VSCode is automagically passing --debug-brk argument to heroku, causing the error:
/usr/local/bin/heroku --debug-brk=23080 'local web' app.js
! `--debug-brk=23080` is not a heroku command.
! See `heroku help` for a list of available commands.
VSCode also does not find heroku command without its full path (seems like it is not loading PATH environment variable).
Any ideas about how to setup the editor?
The following solution works for me:
1) In your procfile add the parameter --debug to the node process
web: node --debug server.js
By default the debugger listens in the port 5858
2) Once you have the node process running, open VSCode and add the following configuration to your launch.json file
{
"type": "node",
"request": "attach",
"name": "Attach to Process",
"port": 5858
}
3) Finally, click the play button in VSCode with the option "Attach to Process" and it should debug your process.
The following solution worked for me.
In my package.json "scripts", I added:
"debug": "node --inspect-brk server.js"
Then, in launch.json I added an envFile entry to the default "Launch via NPM" configuration, which now looks looks like this:
{
"type": "node",
"request": "launch",
"name": "Launch via NPM",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run-script",
"debug"
],
"port": 9229,
"envFile": "${workspaceFolder}/.env"
}
The above solution enables the VSCode debugger to run my server via an npm script, and my server runs with the env vars set in my .gitignore'd .env file, just like in the "regular" Heroku node.js workflow.
I struggled with this as for some reason the solution propsed didn't work for me. However, an alternate solution did so I thought I would share.
From the default debugging options in VS Code choose
Attach by Process ID
When you start the debugger with this configuration it should list available processes to attach to and one should be simply be server.js. This requires manually attaching each time, and if the other automatic attachment works for you that may be better, but this is still a workable solution.
I tried to use the simple node.js example visualstudio code provides, but unfortunately when node is being started from visual studio code (on OS X) the node gets started with some arbitrary debug-brk, but debugger attachment fails.
When I run the node app manually with --debug-brk = 5858 and then use the attach I can debug my app. Anyone faced the same problem?
P.S I got mono installed from the mono project page .pkg
Here is my launch.js:
{
"version": "0.1.0",
// List of configurations. Add new configurations or edit existing ones.
// ONLY "node" and "mono" are supported, change "type" to switch.
"configurations": [
{
// Name of configuration; appears in the launch configuration drop down menu.
"name": "Launch app",
// Type of configuration. Possible values: "node", "mono".
"type": "node",
// Workspace relative or absolute path to the program.
"program": "./bin/www",
// Automatically stop program after launch.
"stopOnEntry": true,
// Command line arguments passed to the program.
"args": [],
// Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
"cwd": ".",
// Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
"runtimeExecutable": null,
// Environment variables passed to the program.
"env": { }
},
{
"name": "Attach",
"type": "node",
// TCP/IP address. Default is "localhost".
"address": "localhost",
// Port to attach to.
"port": 5858
}
]
}
Just ran into the same issue... Code couldn't find Node.
Change this line to point to your executable, for example:
"runtimeExecutable": "C:/Program Files/nodejs/node.exe",
Enjoy!
Might be the cluster thing. Try to turn off cluster in ./bin/www, and you will be able to debug it.