I have been following the Microsoft azure developers online course and i have started an exercise on durable functions
First thing i had to do was to use Kudu to install the durable functions package via a package.json file
all details are in this link
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-create-portal
After this i had to create a new HTTP start function (details also in the above link) but the install does not complete successfully (see attached screen shot)
I have tried this a few times and no joy and unable to continue the course until i get this resolved
screen shot shows the errors and no matter how long i leave it it never completes
have also tried restarting the function and try again but no luck
screen shot - error installing HTTP start
ok i have now overcome this
Details of the fix are in this link
https://github.com/Azure/azure-functions-host/wiki/Updating-your-function-app-extensions
its important to stop the function otherwise you don't see the bin folder and the .csproj file you need to edit
Related
Hey I have deployed new azure function using Azure dev ops CI/CD. The function app has been deployed successfully and when I go to the main URL, it says your function app is running. I tried to test the end points("/save") using azure portal and the output is 404 Not found. The same results when I use POST man as well. Any help would be appreciated?
2020-11-21T11:30:45.769 [Error] The following 2 functions are in error:
Get: The function type name 'DocumentContextFunction.Functions.GetDocument'
is invalid.
Save: The function type name
'DocumentContextFunction.Functions.SaveDocument' is invalid.
I have fixed this by updating the value of the "FUNCTIONS_EXTENSION_VERSION" from 1 to 3. For some reason every time I deployed using Azure CI/CD, its value is set to 1, so I have to manually change it to be 3.
I encountered this error when my build targeted win-x64 whereas the Azure Function Platform was configured as 32 bit.
In my case I had a function created in portal. I then published a function via visual studio. After publishing the portal created function was 404 not found and I could not even delete the function from the portal.
Exact same code in a new function worked as expected.
This is not intuitive and were no indications in the portal that previous portal created functions would break.
This maybe buried somewhere in documentation but I would have expected a warning in azure before allowing other functions to break without code changes.
The author's question helped me understand where the problem was coming from. In my case, it was not about the CI/CD pipeline doing anything funny.
It was my IaC code which was not setting up the function app properly. It picks version ~1 by default but I had to set it to ~3.
My function apps were working until I included a new custom package with a later version of Microsoft.Extensions.Logging. My functions were using Microsoft.Extensions.Logging 2.1.1. The package had version 7.0.0, which is for Net7. It was incompatible with my Net6 projects.
When the package was added, the Microsoft.Extensions.Logging version in my project was updated to 7.0.0. The were no compile errors, but debugging showed that the assembly could not be loaded. This was causing the 404.
Changing the package version back to 2.1.1 corrected the problem.
This is what worked for me...
Note: I was getting 404 on my function which is a nodejs and inline editing on the browser.
Open your function.json and take a backup as we are going to change it.
See if in your function.json there are two different settings with "direction": "in"
For me there were two. I tried deleting but it keep coming back.
Next I went to 'Integrations' (on left menu) and opened my trigger and deleted it. This will recycle your trigger. And hope this works for you too.
I'm looking for a way to perform a hard reset on a NodeJS Azure Function that gets uploaded through VS Code? It's v2 of the Azure Functions.
Things I have tried
restarting the Azure Function via the portal
stopping/starting the Azure Function via the portal
removing the bin, obj, extensions.csproj and node_modules from the VS Code project and re-installing
The reason why I'm looking to do this is that I have updated a local package through npm install --save <my new module>, but it isn't running the latest package when I invoke my Azure Function after uploading with the updated package through VS Code. I have verified that the package was updated by reviewing the package.json file and the source in node_modules (on VS Code and in Kudu on the portal). My hypothesis is that by not changing the Azure Function's source code, the Azure Function doesn't reload with the new package, which seems like it could likely be a bug. I would prefer if I don't have to change the source every time I update the node_modules, which is why I'm looking for the reset.
Related except for C# - does't seem to make a difference with NodeJS
Any guidance is appreciated.
There're few things to try out here:
Please go to the Kudu website of your function app (url => https://{your-function-app-name}.scm.azurewebsites.net/) and navigate from "Debug console" menu >CMD/PowerShell, and:
Please check folder site>wwwroot>node_modules and make sure than expected module version is present there
If not then please make sure that the package-lock.json is pinning to a specific version of a module, and also please make sure that modules and their version in package.json and package-lock.json are as expected
Also, to reset the function app, you can add a test app settings {"testKey", "testValue"} which will cause your app to restart and pick up the new modules, and once the function picks up the new module then you can clean up this test app settings
I keep getting this message whenever I try to debug an azure function in VS2017 and I can't figure out why.
Any input or assistance appreciated.
It appears to be looking for some kind of azure web jobs library:
This 'System.Threading.Tasks.TaskCanceledException' in System.Private.CoreLib.dll should be a first chance exception when function is triggered, no need to worry as it has been handled by function host.
If you don't see any red error info in function cli window (pop out when debugging) and your code is successfully executed, this should be an internal error.
Can't reproduce it on my side, hence just offer some suggestions based on my understanding.
Delete function sdk folder %userprofile%\.nuget\packages\microsoft.net.sdk.functions and install latest 1.0.14 package in your function project.
If it doesn't work, I recommend you to download VoidMethodInvoker.cs or JobHost.cs to detect the exception. Then ignore it by configuring Exception settings. Met an internal exception on queue trigger before.
I met an issue when using Azure function.
I create a Azure Functions v1(.Net Framework) Http Trigger template in VS. But when I try to run it directly, exceptions thrown.
I am using latest version of VS(15.6.7) and Azure Functions and Web Job tools(15.0.40502.0).
When I run it first time, no prompt for installation of anything, it runs on 1.0.10 Azure Function CLI. After I restart my VS and try to run it again, VS asks to download 1.0.12.1 Function CLI. The download seems failed as I still see 1.0.10 on the tile of window. The exception remains all the time.
Any idea? It doesn't make sense since I just try to run a template.
The root cause is shown in your screenshot.
Starting Host(...,Version=1.0.11232.0)
It means your function Cli is 1.0.4 other than 1.0.10 actually, here's release note of 1.0.4. After tests, find that old version does cause this exception. This version issue roots in failing to download latest Azure Function Core Tools trough VS.
Update for official solution
Handle downloading problem of Azure Function Core Tools. Try the first option to download using VS again, if it still fails, use the second option, PS scripts.
Below is the original solution, similar to the first and third official option, just ignore it
More Details
Azure Functions and Web Jobs Tools is updated to 15.0.40502.0 recently and mechanism of using local function Cli is also changed. Release Notes.
Tools now consume a feed which keeps templates, build tools, and the runtime up to date whenever there is a change made in the service.
The first time we create an Azure function after this update, we can see the tip on the dialog Making sure all templates are up to date.... It means VS is downloading necessary cli and templates to this folder C:\Users\UserName\AppData\Local\AzureFunctionsTools.
After a while, we can see the tip changes as
If we don't wait the downloading to complete and create project directly, it will prompt that VS is downloading 1.0.12.1 Cli. And everything should work fine after that.
As for your problem, I reproduce it once due to slow network. It fails to download those files and tries to use old version cli downloaded by VS before.
Solution
I recommend you to delete AzureFunctionsTools folder and restart your VS to download it again.
If it still fails to download, you can download it manually.
You can find download link of cli, itemTemplates and projectTemplates in C:\Users\UserName\AppData\Local\AzureFunctionsTools\feed.json.
And the folder structure in C:\Users\UserName\AppData\Local\AzureFunctionsTools\Releases\1.0.12.1 is like this
cli
--func.exe
....
templates
--ItemTemplates.nupkg
--ProjectTemplates.nupkg
manifest.json
Content of manifest.json
{
"ReleaseName": "1.0.12.1",
"CliEntrypointPath":"C:\\Users\\UserName\\AppData\\Local\\AzureFunctionsTools\\Releases\\1.0.12.1\\cli\\func.exe",
"TemplatesDirectory": "C:\\Users\\UserName\\AppData\\Local\\AzureFunctionsTools\\Releases\\1.0.12.1\\templates",
"FunctionsExtensionVersion": "~1",
"SdkPackageVersion": "1.0.13"
}
quick question.
I've been going through the google actions tutorials and sdk and quickly went through their github located at:
https://github.com/actions-on-google/dialogflow-webhook-template-nodejs
I followed the steps to initialize my firebase client and put in the addMessage and makeUppercase functions. Per the next step I did a firebase deploy --only functions, but this is where it gets weird.
In the sdk read.me it says it should output a link that looks similar to:
https://${REGION}-${PROJECT}.cloudfunctions.net/yourAction
However the link that terminal spit out for me was a link to my function "console" and the link looked like:
https://console.firebase.google.com/project/"my project name"/overview
I'm curious where I went wrong here as I simply copy and pasted the functions step by step and then deployed as they said.
Is this just how firebase returns the functions now? Maybe there was an update since the node.js sdk was published the other month? I'm worried that this outputted link is not the correct one for my webhooke in dialogflow. When I go to my console link, I can't find anywhere that gives me a link for a webhook within that dashboard so I'm a bit confused here
EDIT: So I dug deeper in their resource page, it's telling me it should output both my Project Console link as it did above as well as the function link. The function link is not being shown, which is leading to my confusion. Any idea as to why the function link is not being created?
The Firebase command line tool has changed something recently, so it only reports that URL the first time a function gets deployed. Or something like that.
The canonical way to get the URL for your function is to
Go to the Firebase Console (https://console.firebase.google.com/)
Login and select your project, if necessary.
Click on the "Functions" menu item on the left, which may be grouped under the "Develop" section.
In the center area, you'll see the function you have deployed for that project, along with the URL for it.
I went and deleted everything and tried again, now the function url is showing when I deployed my functions. I think what had happened before is I had ran an npm init on my folder out of habit before doing my firebase stuff, and when using firebase functions it will build the node dependencies for you as part of the process. I think running this early npm init screwed something up and was causing my firebase commands to act weird.