As title, when I try to run my nodejs based azure function, I come across the following error:
The following 1 functions are in error: [7/2/19 1:41:17 AM] ***: The binding type(s) 'blobTrigger' are not registered. Please ensure the type is correct and the binding extension is installed.
I tried func extensions install --force with no luck still, any idea? My development environment is macOS and I tried both nodejs based azure-functions-core-tools and brew based install both doesn't work.
The most scary part is this used to work fine on the same machine, all a sudden it just failed to work.
Basically, you can refer to the offical tutorial for Linux Create your first function hosted on Linux using Core Tools and the Azure CLI (preview) to start up your work.
Due to the same shell bash used in MacOS and Linux, I will start up my sample demo for you on Linux and avoid using those incompatible operations. First of all, assumed that there is an usable NodeJS runtime in your environment. The version of node and npm is v10.16.0 and 6.9.0.
To install azure-functions-core-tools via npm and inspect it, as the figure below.
Next to init a project MyFunctionProj via func
Then to new a function with blob trigger
There is an issue about the requirement for .NET Core SDK. So I move to https://www.microsoft.com/net/download to install it, here is incompatible with MacOS, but I think you can easy to fix it by yourself. So I followed the offical installation instruction to install it.
After installed .NET Core SDK, try to func new again.
And completed like this.
To change two configuration files MyFunctionProj/local.settings.json and MyFunctionProj/MyBlobTrigger/function.json, as below.
MyFunctionProj/local.settings.json
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "node",
"AzureWebJobsStorage": "<your real storage connection string like `DefaultEndpointsProtocol=https;AccountName=<your account name>;AccountKey=<your account key>;EndpointSuffix=core.windows.net`"
}
}
MyFunctionProj/MyBlobTrigger/function.json
{
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",
"direction": "in",
"path": "<the container name you want to monitor>/{name}",
"connection": "AzureWebJobsStorage"
}
]
}
Then, command func host start --build to start up it without any error.
Let's upload a test file named test.txt via Azure Storage Explorer to the container <the container name you want to monitor> which be configured in the function.json file. And you will see that MyBlobTrigger has been triggered and work fine.
Hope it helps.
Related
I'm trying to trigger an Azure Function when a Web PubSub message is published.
According to the example in this article, I should be able to use the following to trigger a function when a new message is sent to a specific hub...
{
"disabled": false,
"bindings": [
{
"type": "webPubSubTrigger",
"direction": "in",
"name": "data",
"hub": "ABC",
"eventName": "message",
"eventType": "user"
}
],
"scriptFile": "../dist/WebPubSubTrigger/index.js"
}
However, I keep getting this error whenever I initialise the function app...
The 'WebPubSubTrigger' function is in error: The binding type(s) 'webPubSubTrigger' were not found in the configured extension bundle. Please ensure the type is correct and the correct version of extension bundle is configured.
Here's my extensionBundle config in host.json...
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[3.3.0, 4.0.0)"
}
But this article does not have it listed as a supported binding type so I'm a little puzzled to say the least!
Can anyone point me in the right direction please?
I'm running my Functions in a NodeJS environment but that shouldn't make a difference I don think.
I have also already tried installing manually, as per below, but tells me it's already installed 🤷🏽♂️
Me | Tue 28 # 15:49 ~/Development $ func extensions install --package Microsoft.Azure.WebJobs.Extensions.WebPubSub --version 1.0.0
No action performed. Extension bundle is configured in /Users/me/Development/host.json`
According to the extension bundles versions available, setting the version to [3.3.0, 4.0.0) should do the trick looks like. Do note that this will update other extensions as well. So, it would be best to test that other functions are not breaking do to this change
Another option would be to just install this extension explicitly with this command as mentioned in the Web PubSub docs.
func extensions install --package Microsoft.Azure.WebJobs.Extensions.WebPubSub --version 1.0.0
I want to use Node.js v12.x to build and deploy but it uses 14.15.1:
Using Node version:
v14.15.1
Using Npm version:
6.14.8
If you arrived here wanting to set the Node.js runtime version that is used for your API backend, refer to https://learn.microsoft.com/en-us/azure/static-web-apps/configuration#platform
In summary, you will create a staticwebapp.config.json that sits where your app_location is pointed in your github workflow (typically the root of your project) or any subfolder of app_location
You can then set the runtime like this...
{
"platform": {
"apiRuntime": "node:16"
}
}
At the time of writing, your options are node:12, node:14, node:16. Reference the link above for the most up to date values.\
I'd like to answer the original question as well because I think the accepted answer is wrong. The azure CLI will say that az webapp ... can't find your project because it's a staticwebapp not a webapp.
The solution (and I'm not certain) should be to set the nodeEngines in package.json, like this:
{
"engines": {
"npm": ">=7.0.0",
"node": ">=16.0.0"
},
"dependencies": {
...
}
}
If I'm wrong about this, let me know in the comments and I'll update it.
You can set the desired node.js version via the Azure CLI:
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|12.X"
For more information, see https://learn.microsoft.com/de-de/azure/app-service/configure-language-nodejs?pivots=platform-linux#set-nodejs-version
I'm presently hosting an Azure Scale set running Windows Server 2012 R2 that is setup with the Chef extension (Chef.Bootstrap.WindowsAzure.ChefClient). When the VM is provisioned, the extension reports back that it succeeded via the Azure portal however the registered node on the Chef server is not updated to retain the provided run list and the first run isn't fully completed. This is causing subsequent chef-client runs to be performed with an empty run list. When I observe the reports on chef server, I see a run with a status of aborted with no error.
Upon review of the WindowsAzure Plugins chef-client.log file, I can see that it tries to execute the run list but seems to be interrupted with the following FATAL
FATAL: Errno::EINVAL: Invalid argument # io_writev - <STDOUT>
There is no chef-stacktrace.out file created as well. The ARM extension definition looks like:
{
"type": "extensions",
"name": "ChefClient",
"properties": {
"publisher": "Chef.Bootstrap.WindowsAzure",
"type": "ChefClient",
"typeHandlerVersion": "1210.12",
"autoUpgradeMinorVersion": true,
"settings": {
"client_rb": "ssl_verify_mode :verify_none\nnode_name ENV[\"COMPUTERNAME\"]",
"runlist": "recipe[example]",
"autoUpdateClient": "false",
"deleteChefConfig": "false",
"bootstrap_options": {
"chef_server_url": "https://mychefserver.com/organizations/myorg",
"validation_client_name": "myorg-validator",
"environment": "dev"
}
},
"protectedSettings": {
"validation_key": "-----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----"
}
}
}
In order to troubleshoot, I've tried to reduce my example cookbook down to a single DSC script which installs IIS. Even this step, I've executed it multiple ways such as using windows_feature, powershell_script, and dsc_script. All result end up with the same error. Here is the current script
powershell_script 'Install IIS' do
code 'Add-WindowsFeature Web-Server'
guard_interpreter :powershell_script
not_if "(Get-WindowsFeature -Name Web-Server).Installed"
end
If I override the run list and call chef-client manually, everything succeeds. I'm having trouble honing in on whether this is the Azure Chef Extension, the Chef client, or the cookbook.
As far as I can tell, communication with the Chef server looks good as the necessary pem files are exchanged, chef-client is installed, and the cookbook is downloaded and cached from the server. The cache gets removed on the subsequent run however with the empty run list. Here are the contents of first-boot.json:
{"run_list":["recipe[example]"]}
Here are the versions in play:
chef-client version: 14.1.12
Azure Chef Extension version: 1210.12.110.1001
Server version: Windows Server 2012 R2
Any ideas what could be going on?
It turns out my analysis was incorrect about which resource was causing the problem. It appears that the first boot run was failing when using dsc_script as the resource to install the web server. When using the following powershell_script resource, it succeeded and the run list attached for future runs.
powershell_script 'Install IIS' do
code 'Add-WindowsFeature Web-Server'
guard_interpreter :powershell_script
not_if "(Get-WindowsFeature -Name Web-Server).Installed"
end
I am setting local host port in local.setting.json. Referring Microsoft doc https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local
The file looks like below
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "",
"AzureWebJobsDashboard": ""
},
"Host": {
"LocalHttpPort": 7073
}
}
When I run/debug the solution , VS still host the app on default port (7071)
I have checked the bin directory, the local.setting.json file is geting there with above settings.
Running Azure Fucntion CLI (func host start) from bin directory correctly read the port number.
Looks like VS is not using the "LocalHttpPort" port. Is there any other changes required in the settings. I have Visual Studio 2017 Preview (2)
I am using the CLI version 1.2.1, and the following Application arguments setting in Project Properties -> Debug worked for me.
host start --port 7074 --nodeDebugPort 5860
Update: If you're just looking to change the port, you don't have to set it through the file specified in the question. Check Thuc Nguyen answer
Original answer:
the command line takes precedence over the settings file, the problem is that VS passes an explicit port on the command line.
work around is to go through project -> properties -> Debug, then under Application arguments take control of the args. you can type host start --pause-on-error
Edit from ravinsp:
Update for .Net Core 2.0 function project:
The command line arguments you have to pass are different. You have to pass in the path to a dll in front. Like this:
%AppData%\..\Local\Azure.Functions.V2.Cli\2.0.1-beta.22\Azure.Functions.Cli.dll host start --pause-on-error You can see for yourself by running the function in Visual Studio and using the process explorer to see command line args to dotnet.exe process.
edit: a word
Update Project Properties -> Debug to following
host start --port 7073 --pause-on-error
As of this version:
Azure Functions Core Tools (3.0.2912 Commit hash: bfcbbe48ed6fdacdf9b309261ecc8093df3b83f2)
Function Runtime Version: 3.0.14287.0
you only have to type start --port 7074 in the Application Arguments box
Correct answer for .NET Core 2.0 / .NET Standard 2.0 Azure Functions project in Visual Studio 2017 when you have installed Azure Functions Core Tools 2.x Runtime via NPM
I followed #ahmelsayed's answer and in particular, #ravinsp's comments for .net core 2.0 comments. While very helpful and putting me on the right track, they did not work for me without a crucial and non-intuitive modification so I'm adding a fresh answer.
TL;DR;
If you've used NPM to install Azure Functions Core Tools 2.x Runtime then you may need to set Project/Properties/Debug/Application Arguments to:
C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.dll host start --port 8888 --pause-on-error
Long answer follows ...
My Setup
During this exercise, my setup is fully up to date (at time of writing) and as follows:
Visual Studio 2017 Professional: 15.6.2
Azure Functions and Web Job Tools: 15.0.40215.0
Windows 10 10.0.16299 Build 16299
Azure Functions Core Tools (installed as per the Develop and run Azure functions locally document from Microsoft) reports (in Git Bash):
me#MYDESKTOP ~
$ func
<snip/>
Azure Functions Core Tools (2.0.1-beta.24)
Function Runtime Version: 2.0.11587.0
fwiw, the Functions App settings tab for this Functions App on Azure reads:
Runtime version: 2.0.11587.0 (beta)
My Issue
When I run my functions project (with no application arguments) I get this in the console output:
[17/03/2018 21:06:38] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=<snip/>
Listening on http://localhost:7071/
This in and of itself might not be a problem, but I'm getting annoying "works on my machine, fails when publishing to azure" type issues, so I want to make sure that local execution is using same functions runtime as azure (i.e. 2.0.11587.0 which, as per the setup notes above, it is/should be, right?)
So, based on #ravinsp's instructions, I run a find on my C drive to locate Azure.Functions.Cli.dll - there's only one, and it's located at C:\Users\<myuserid>\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll which seems very consistent with #ravinsp's answer.
So, I add the following Project/Properties/Debug/Application Arguments:
C:\Users\<myuserid>\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll host start --port 8888 --pause-on-error
then I DO get port 8888, but runtime weirdly is still being reported as 2.0.11353.
[17/03/2018 21:13:02] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=<snip/>
Listening on http://localhost:8888/
Solution
Given that running func from Git Bash as per the above showed runtime of 2.0.11587.0, I tried which func which returned /c/Users/<myuserid>/AppData/Roaming/npm/func
. I did a cat on it and long story short I could see that ultimately it was running C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe, and that in that same directory there was a func.dll.
So, I tried the following Project/Properties/Debug/Application Arguments:
C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.dll host start --port 8888 --pause-on-error
then finally I do get ...
[17/03/2018 21:16:29] Starting Host (HostId=MYMACHINE, Version=2.0.11587.0, ProcessId=<snip/>
Listening on http://localhost:8888/
and, crucially, the error I was getting when publishing to Azure starts manifesting itself locally too.
Ok, now the runtimes all in sync, time to get down to fixing my actual bug :)
To do this
Select the Function App Project in Visual Studio -> Hit Alt+Enter and navigate to Debug settings and set
host start --port 8085 --nodeDebugPort 6890
I used the accepted answer but I still got an error when the debugger port was trying to bind because both function apps were trying to bind to 5858.
To get around that I added one more attribute to the application arguments in the project settings and my arguments look like this:
host start --pause-on-error --nodeDebugPort 5860
If you're using Visual Studio for MacOS right click on your project, click Options, click on Run -> Configurations -> Default and enter host start --port 7073 --pause-on-error in the Arguments field.
Using Visual Studio 2022 and Function v4, you could set the port in the launchSettings.json file:
{
"profiles": {
"<functionapp project name>": {
"commandName": "Project",
"commandLineArgs": "--port 7137",
"launchBrowser": false
}
}
}
This setting can also be updated through UI:
Properties > Debug > General > Open debug launch profiles UI:
This is the way I use a different port in local.settings.json file, while running this in Intellij. You can use any other IDE as well, local.settings.json works everywhere.
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "java"
},
"Host": {
"LocalHttpPort": 7072
},
"ConnectionStrings": {}
}
Using the following in the "Command line arguments" in VS 2022 and .Net 6 works:
start --port 7074
I'm testing an Azure Functions app locally with the Azure Functions CLI tooling. Is there any way I can configure CORS settings for the local host?
You can configure CORS in the local settings file local.settings.json:
{
"Values": {
},
"Host": {
"CORS": "*"
}
}
Settings in the local.settings.json file are used only when you're
running projects locally
You can start the host like this
func host start --cors *
You can also be more specific and provide a comma delimited list of allowed urls
More here: https://github.com/Azure/azure-webjobs-sdk-script/issues/1012
Another easy way to configure CORS on Azure Functions is to use Azure Portal,
1- Go to the Function App Settings in Azure Portal
2 - Click on CORS and add your local host url
And there you have it!!
Hope this helps someone.
If you're having issues passing in the params via Visual Studio's Debug's "Application Arguments". This is how to pass the params from the command line:
1) Open an ordinary command prompt.
2) cd to your solution's compiled dll, i.e. "Your Solution Path"\bin\Debug\netstandard2.0
3) start the Azure function runtime from the command line, i.e.:
dotnet "C:\Users\USER\AppData\Local\Azure.Functions.V2.Cli\func.dll" host start --port 7071 --cors * --pause-on-error
4) To debug in Visual Studio, Debug->Attach to Process.. and attach to the donet.exe that will be running.
Hope that helps prevent someone from banging their head too much...