where is function.json file in Visual Studio 2017

[melzoghbi]

Hi,

I am using Visual Studio 2017 Preview and latest Azure function tooling. I want to be able to work on function.json in Visual Studio as Azure Portal generates when creating bindings into my VS functions.

Is there away to copy these settings so i can customize it as needed in VS 2017 without the need to run it from the portal? Do i need to create it? or can i use local.settings.json file?

Let me know.

Thanks a lot.

[sjkp]

It gets generated on build and placed in the output folder. So I guess you can make a post build event that manipulates it if you need to.

[lindydonna]

You should use app settings via "%Setting%" and customize with App Settings in Azure. We do not recommend editing function.json after it's been generated. In the next version of the tooling, you will get a runtime error if you edit the file, because input and output bindings will be read directly from the assembly attributes.

[sjkp]

Why would you change that behavior @lindydonna? Now I can deploy the same code X times but change the function.json file for each instance to let it read from e.g. different queues. If you force me to use the code, I no longer have that option without doing more work, e..g a setting can only point to one queue. So I have to do the webjob queue name resolver if that is even supported in function. Also it is not logical that C# functions should work differently than others types of functions and not respect function.json. If you want to no longer depend on function.json I think you should do that in version 2.0 as it is a breaking change, not something you should change with a VS tooling update.

[TheeJamesLee]

@sjkp I think you've read her reply wrong (or at least the intention). (For ref I am only referring to the Azure Functions 'compiled app' tooling)

The %Setting% approach is reading the setting from a config file. local.settings.config for local development. When it is deployed onto a Web App it is reading from the Web App Config settings on Azure. So rather than having a 'unique' function.json per deployment... the settings are defined by 'where' it is deployed, ie the Web App instance itself.

I don't think that that is actually a change from having a function.json per deployment location to reading from Web App settings (not sure they even changed to that - quite sure they have done it all along).

I can see that if your CI process is changing values in the function.json file it will cause a problem - however my opinion would be that that approach wouldn't work long term anyway. If you're publishing from Visual Studio, then the 'queues' you want to read from are more infrastructure in your case so actually being a setting on the web app is more useful (Because you didn't mention you were dynamically deciding a queue name... it's hard coded in function.json in your explanation above). If you're deploying your infrastructure via ARM, then it makes sense to wire the connection strings up to the web app for example.

Hope that helps,

[sjkp]

My use case is that I have a single function app, with many maintenance functions. All the maintenance functions are doing the same, but on different "resources", queues was just and example. Rather than making several functions apps (which I could) I have decided to collect it all in one, and do the configuration of each maintenance function in the function.json at its deploy location. If the function.json is not respected I cant do this anymore. What would the recommended approach then be going forward to create a function app for each maintenance function?

My function.json files gets generated/modified programmatically, lets just call say it's part of the CI pipeline (it is actually an application that creates the function app).

[TheeJamesLee]

Interesting. I can see your dilemma.

I am guessing that the resources are 'identical', ie, only the location of them is different.. the schema, etc is identical and that are accessed the same way.

I would do the following (thinking about it I may need to do this at some point myself..). I would move the 'resource list' out of the app (including function.json in the app, due to Compiled). The reason is that if I wanted to change, ie, add / remove, a resource I need to recompile the application (Yes, earlier function's I could have just pushed a new function.json, however I personally view 'Compiled Functions' as a 'new' style).

I would maybe use Azure Table storage with some example columns : Id (resourceidentifier), Partition ("X"), Url (location..), AccessToken, TimeAdded ....

In the 'single function' that describes the "what to do to the resource" .. aka your 'maintenance function'. I would add a binding to that Azure Table to get all the rows.

• Depending on the work.

If it was quick and infrequent - milliseconds duration per and once an hour - I'd just have that function run looping through each row off a timer trigger.

If it was long and frequest - minutes duration per and once per hour (and say 100 resources) - I'd 'queue' up jobs for each resource in a 'pre function' off a timer trigger and add some kind of de-dup either before the 'worker' or in the 'worker' (either service bus with a filter / the actual worker function doing a pre check). 'worker' would be your current maintenance function but off a queue trigger.

Cons;

• a little more complex potentially.

Pros;

• adding/removing resources is outside of the responsibility of the function itself.
• can be further abstracted if wished (ie another function on a timer uses the ARM rest api's to find all resources of a certain type and prefix and adds/removes from that Azure Table list).

[lindydonna]

To clarify, if you use WebJobs attributes, by default a setting will be added to the generated function.json to specify that the attributes take precedence. Also, only triggers will be generated. If you want to control the config, then you should not use attributes and instead use function.json directly.

The reason for this is that the process of generating function.json is error prone, and the functions runtime already executes based on attributes.