Azure Functions, function.json, Visual Studio 2022 and proxies.json, deploy, deployment

A few interesting scenarios I experienced that I wanted to document.  Firstly, there is a lot of focus on Visual Studio Code, I’m still working on ramping up there and aligning with and contributing the momentum it is building.  I see Visual Studio Code as the place where those who want to get into Open Source stuff, but have been with Microsoft for long time.  If you are going to learn some new coding language, might as well use the IDE which is focused there.  That’s not saying that Visual Studio (not Code) doesn’t support Open Source, it does, but like I said, why not align totally with the momentum if you are dipping into Open Source.

Anyway, I was trying to do some testing and wanted to add a file, specifically the proxies.json to an Azure Function.  I added it to the root of my project, as shown, but when I deployed it did not show up.

image

Figure 1, adding files to an Azure Functions Visual Studio 2022 project

The thing is, when you deploy an Azure Function it is defaulted to run WEBSITE_RUN_FROM_PACKAGE.  This if fine and optimal.  What this means is if you try to add the Proxy manually, you cannot because the Azure Function is in read-only mode when WEBSITE_RUN_FROM_PACKAGE is enabled.  Trying to temporarily setting WEBSITE_RUN_FROM_PACKAGE to 0 will not work either.

image

Figure 2, cannot make changes to an Azure Function when WEBSITE_RUN_FROM_PACKAGE is enabled

The solution is to modify the properties of the proxies.json file so that it gets copied into the Output Directory.  Once that happens, all is good.

image

Figure 3, change file properties to include the file in Visual Studio build

Which leads me to the real challenge I had, which was making a change to the functions.json file in Visual Studio, which again, did not publish when I changed it.  I wanted to set IsSessionEnabled = true for a Service Bus triggered Azure Function.  So, I went to the source.  That means, the files are generated during the build, so I modified the function.json file in both the Debug and Release directory, but the change was overwritten during the build process.  I think this is by-design.

  • C:\Users\benperk\source\repos\csharpguitar-vs\csharpguitar-vs\bin\Release\netcoreapp3.1\servicebus
  • C:\Users\benperk\source\repos\csharpguitar-vs\csharpguitar-vs\bin\Debug\netcoreapp3.1\servicebus

I thought, hey it worked for proxies.json, when not use that same approach with this function.json.  So I clicked the Show Hidden Files button and navigated to the function.json, clicked it and didn’t see any properties that would let me include this file into the Output Directory, it was empty.

image

Figure 4, where is the function.json, include changes with Visual Studio

What lead me to a working solution was this comment in the GitHub article I linked to above, here it is again incase you missed it: “because input and output bindings will be read directly from the assembly attributes”.  So the solution for me was to add the binding attribute in the Run() method declaration directory in the code.

image

Figure 5, function.json changes do not deploy with Visual Studio, how to

public static void Run(
   [ServiceBusTrigger("csharpguitar", IsSessionsEnabled = true, Connection = "SB_CONN")]string myQueueItem, ILogger log)
   {
       log.LogInformation($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
   }

The confusing part of this is that I wanted to place also set autoComplete = false, but you cannot do that in the Run() method declaration, or at least I didn’t find it.  Instead you set that in the host.json.  The documentation does state that autoComplete is a function.json attribute.  The thing is, your Run() runs within the Azure Functions Host, so apparently the management of the autoComplete capability was coded into the host, which the implementation of the Session Management is in the Function. 

Either way, I am successful now in my effort and I can proceed with the work I need to complete that required me to learn what I documented here before I could start it.