I have an azure function that I want to report what version of the code it is running. In other applications I am able to get this by running something of the nature:
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version
However I don't a) seem to have away of putting that data into the azure function (there is no assembly information button) or b) retrieving that information (the above code snippet always returns 1.0)
Is there a way (other than just putting in a configuration setting or private variable) to pull a standard version value from an Azure function via this mechanism?
I assume you are currently using .csx files from the Azure portal. If you instead switch to using Visual Studio and precompiled assemblies (which is generally recommended) the code you have above should work fine.
Specifically, use the following steps to change the version:
Right click on the Project and choose Properties
Go to 'Package'
Change the Package version
Related
I've been working on a small function to automate my certificate renewal in Azure Functions.
The function works in my local emulator (in vscode), running under node v10.15.3.
However, when running it online, an exeption is generated on the syntax of an async iterator when the file containing it is included
Stack: /home/site/wwwroot/node_modules/acme-dns-01-cloudflare/index.js:125
for await(const zone of consumePages(pagination =>
It's my understanding that this syntax has been adopted in node versions 10.x. I therefore added the console output line: console.log(process.versions); and get the response that the function is running node version 8.16.1. I therefore checked the WEBSITE_NODE_DEFAULT_VERSION application setting, and confirmed it is set to 10.14.1. I have also checked it with another recommended setting of ~10 and got the same result.
Unfortunately the documentation is difficult to search for such a specific issue, but I have not yet come across anything that states that Linux functions are limited to node v8.x
As extra information, the FUNCTIONS_WORKER_RUNTIME is set to "node", and the runtime version is 2.0.12733.0 (~2)
At time of writing, this issue on github highlights the problem https://github.com/Azure/azure-functions-host/issues/4948. Different node versions are simply not available on Linux consumption plans regardless of the setting in WEBSITE_NODE_DEFAULT_VERSION.
Hopefully their new arrangements will be in place soon for anyone else who has this issue.
For now you can switch to a windows consumption plan, or potentially switch to a service plan (I haven't checked this, as it sort of defeats the point of functions)
Refer to this issue1 and issue2, looks like WEBSITE_NODE_DEFAULT_VERSION won't work for linux function, have to set the LinuxFxVersion property to select the node version.
Follow is my flow to change it.
1.Go to your Function App in the portal and open the Resource Explorer. You will find LinuxFxVersion is node:2.0-node8-appservice.
2.Select the web under config node, then choose the Edit button. Find the linuxFxVersion and change the value to NODE|10.14, after this click the PUT button to update the setting. Then restart your Function, check the node version you will find it's 10.14.
I have an existing set of functions in an Azure Functions App written in C# Script. I've downloaded the zip file from the Azure portal and opened the directory in Visual Code. I can also log on to the Azure account from Visual Code and can see the functions. If I right-click, I get options to start and stop streaming logs
However, I don't know how to configure my environment so that I can edit and debug these functions locally. I've found instructions for creating a new Function App, but haven't found ones that describe how to work with an existing app.
As mentioned in this post, for now we can't debug(add break points to) C# script(.csx) functions in VS Code.
We can only run csx function both on Azure and locally. Open the function app folder in VS code, follow steps below.
Check function runtime version(~1 or ~2) and follow tutorial to install Azure Function core tools.
If we use ~2 runtime, you need to register binding extensions for all triggers/in/output except Http and Timer triggers.
If we want to use settings(like AzureWebJobsStorage) in Application settings, copy them into local.settings.json. Or we can right click on Application settings of the Function app in VS Code, click Download Remote Settings(In this way, some invalid settings for local env are downloaded as well).
Input Ctrl+` to open terminal and input func host start in terminal to run functions.
For local dev, I do recommend you to use C# pre-compiled code instead of C# script, which is much easier to work with. To do this transformation, follow this tutorial, new a c# function app locally, copy your code in .cs files. We basically don't need to modify the logic code except adding some package and namespace references.
I have a Function Apps created via Portal, another one created by visual studio. The latter one cause both apps to become read only, with message below:
Your app is currently in read-only mode because you have published a
generated function.json. Changes made to function.json will not be
honored by the Functions runtime
Is this feature correct?
VS: 15.8.5
Yes, this is by design. Function Apps you mentioned should be called functions in one same Function app.
You create a Function app and a function on portal, then in VS you actually also create a Function app instead of a separate function. After you publish this pre-compiled Function app to the one with some existing functions, Azure thinks you want to use the new published one, so it sets the app to be read-only as we can't modify pre-compiled assets on portal unless we republish our code.
This action is by design because one Function app(with functions inside) is handled as a complete unit. So apparently it's not recommended to mix online development with pre-complied one.
Two choices for you to refer.
Remove existing functions in the app. Check Remove additional files at destination when publishing from VS.
Create another Function app.
There are risks that mixing online and pre-compiled code from VS, for example
Name restriction. Functions created online will be overwritten if we publish functions with same names.
We can't check Remove additional files at destination even though some pre-complied dlls published before have been useless.
If it's only for test or there's no worry about potential risks, just change Function app edit mode to readwrite in Function app settings or add FUNCTION_APP_EDIT_MODE readwrite in Application settings.
I'm new to Azure Functions and been thrown into a project without a proper introduction and anybody I could ask is out of office. My simple most likely stupid question is; where can I find the actual code?
In the azure portal, the functions are listed as "read-only" and only contains a function.json. The resource is an App Service and it has a couple of functions. There is no link to any git repository in properties.
Read-only Functions would be compiled and published (e.g. through Visual Studio or a CI/CD pipeline.) The Azure Functions Portal engineers are working on a new, improved experience for this but for now, if your Function app has a deployment source configured, you can view it from the Portal in two ways from your Function app:
Platform Features > Deployment Options.
Platform Features > Resource Explorer. In the file tree on the lefthand side, find your Function app's name, and under that, sourcecontrols. Click to expand in the righthand window.
If your Function app doesn't have a deployment source configured (e.g. your team has been publishing code manually) then things get harder. Depending on how your company has set up their source control and what you already have access to, the function.json you see might help: the entryPoint property in a build-generated function.json will give you the full assembly name of that function (e.g. VSSample.HelloSequence.Run). That or the assembly name of the uploaded DLL in the scriptfile property might help you locate the project.
Good luck! Keep posting if you have further questions; we're here to help.
AFAIK, if we create the azure function in the Visual Studio and publish it to Azure(there may be other ways), it will appear in the situation you described like the screenshot.
Actually, the code is existing in the portal, but the code has been compiled, you could access it in the Platform features -> Advanced tools (Kudu) -> Debug console.
If you want to get the .cs file, I think you should ask it for your coworkers, there will not be in azure.
You said that the Azure function is listed as "read-only". Did you check from the Application Settings menu if you can change the Azure function app edit mode to Read/Write?
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"
}