Azure-functions-vs-build-sdk: Azure function.json file not copied as output in Visual Studio build anymore?

Created on 22 Nov 2019  路  28Comments  路  Source: Azure/azure-functions-vs-build-sdk

I just upgraded to .NET Core 3.0 SDK, AzureFunctionsVersion v3-preview and Visual Studio Preview 5.0.

Prior to the upgrade my Azure function function.json files would be included in the output

  - debug
    - netstandard2.1
      - bin
      - FunctionFolder1
        - function.json
      - FunctionFolder2
        - function.json

But since the upgrade the function folders are no longer copied as part of the build output.

Has anyone else encountered this issue?

What's interesting is that if I name function.json anything else, for example function1.json or blah.json it copies successfully. It just doesn't work when it's named function.json.

I know I can handle this myself as a post build script but is kind of annoying when this was working.

All 28 comments

@ColbyTresness Looks like a VS bug to me?

@soninaren to take a look

Any progress on this? Same problem for me, with netcoreapp3.1 function v3 and function SDK 3.0.1/.02. same from build script as in VS so apperently not VS.
Everything was working when netcoreapp2.2, functionv2 and SDK 1.0.26-29.

@alexkarcher-msft @jeffhollan

Found a "fix" or "cause" for this issue just now. If not using attributes for functions (in/out etc), but an folder for each function and a function.json, there is a need for copying folder with function.json to build/output/publish.

@helgeu, are you manually creating the folder structure in the publish folder. If yes then you should not need to. Version 3.0.3 of Microsoft.NET.Sdk.Functions should work for netcoreapp3.1. Also Please make sure the AzureFunctionsVersion property in the .csproj. file is set to <AzureFunctionsVersion>v3</AzureFunctionsVersion>.

@patricknolan are you still seeing this issue?

@helgeu, are you manually creating the folder structure in the publish folder. If yes then you should not need to. Version 3.0.3 of Microsoft.NET.Sdk.Functions should work for netcoreapp3.1. Also Please make sure the AzureFunctionsVersion property in the .csproj. file is set to <AzureFunctionsVersion>v3</AzureFunctionsVersion>.

@soninaren

Yeah i have to create those folders manually. They do not appear as expected. And yes I obviously should not need to. And no 3.0.3 do not work consistently for netcoreapp3.1. And yes I have set AzureFunctionsVersion to v3.

See also: https://github.com/Azure/azure-functions-vs-build-sdk/issues/368

its quite easy to recreate. Make a new proj (csproj or fsprj does not matter). Use the default function (http-trigger). Remove attributes from cs-file, and move it to a new folder. Recreate function.json with the attributes. Or use the one generated on compile when first spinning up (found in bin/debug/netcoreapp31/-folder), but then remember to remove some of the elements in function.json. make sure to set function.json to "copy newest".

Expected results: Folder should be created in build and publish folder.

Actual results: somewhat random. Using (dotnet build) build scripts in some circumstances (unknown so far) folders might be recreated in build/publish-folders. In some not. Doing a build in Visual Studio almost always do not recreate folders and function.json in bin/debug/netcoreapp31-folder.

@helgeu, i am having a hard time trying to understand what you are trying to do. Are you expecting a function.json be generated from a .cs file without attributes? The attributes are needed to generate the function.json in the build output. If not, having a stand alone repro would be great. If you have one can you attach it to your response?

@soninaren

try out the following repo doing stuff from readme.

think this is the absolute bare minimum variant of demonstrating the issue:

https://github.com/helgeu/MveFuncBuild

@soninaren did the examples help in describing the issue?

@soninaren Any progress on this ? Older Azure Function version, you could use the Atribute in .cs file then Visual will generate Function.json for you or you can define the Function.json yourself then copy to ouput directory. But new version, when use define the Function.json and mark it with "Copy to output directory", somehow Visual can't copy it. When you start debugging, they report "No job function found" simply because Visual cannot copy Function.json to output directory.

@helgeu and @thaitm312, Sorry it is taking a little time to investigate this. I don't have updated for you so far. Will post an update as soon as i have some information.

cc: @brettsam

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@soninaren any progress in confirming the problem? or solution?

@helgeu -- I don't believe we ever supported defining your own function.json and copying it yourself unless you were using C# script (as opposed to precompiled). I don't recall that this was ever supported via VS and I don't think you'd use the Microsoft.NET.Sdk.Functions package in this case. Do you have a pointer to the docs on this? Maybe it'd make it clearer what approach you're looking at.

If you're trying to use a precompiled build (which we'd recommend), you should use attributes and not check in a function.json. The build tools (which you get via Microsoft.Net.Sdk.Functions) will look at the attributes and generate the correct function.json for you.

@helgeu -- I don't believe we ever supported defining your own function.json and copying it yourself unless you were using C# script (as opposed to precompiled). I don't recall that this was ever supported via VS and I don't think you'd use the Microsoft.NET.Sdk.Functions package in this case. Do you have a pointer to the docs on this? Maybe it'd make it clearer what approach you're looking at.

Thx for your response!

The point here I am trying to make is that I have been doing this for several years. And; No, I did not copy the files my self in earlier versions.

This works excellent and the example project I have put up would work just as described if downgraded to dotnet 2.2, and the project then do copy the function.json as part of the build/publish.

Looking at the documentation at: https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-expressions-patterns

it clearly describes two ways of handling binding expression:

  1. with function.json
  2. with attributes in code

Using method 1. with function.json it is a prerequisite that it gets copied on build as the .proj file is tagged with for function.json, for the function to work.

Did I manage to clarify somewhat better now?

thx in advance!

@brettsam @soninaren did i manage to clarify? any progress on this issue? anything else i could do to make it clearer?

thx in advance.

You're right -- there's no reason you can't directly reference a dll entry point with your function.json. The VS tooling is set up to work off of attributes and auto-generate this for you, but nothing stops you from doing it yourself.

I took your exact project, downgraded it to 2.2 (exact proj file below) -- and it didn't work either. I don't see any http folder in my output, so nothing is found. Can you share a v2 project that works as you expect? Then I can try to see what the difference is is v3.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.31" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="http\function.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

@brettsam

This should do it:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.27" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="http\function.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>
````
Changing the above to same version as you for SDK.Functions: 1.0.31 does also work to, and copies files as expected. 

so this might be a classical "does (not) work on my machine" problem then?

Im using VS2019 latest version on my side. I do have a lot of different SDKs installed etc. Any other info you might need?


From dotnet --info

.NET Core SDK (reflecting any global.json):
Version: 3.1.101
Commit: b377529961

Runtime Environment:
OS Name: Windows
OS Version: 10.0.18363
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.101\

Host (useful for support):
Version: 3.1.1
Commit: a1388f194c

.NET Core SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]
2.1.502 [C:\Program Files\dotnet\sdk]
2.1.503 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.507 [C:\Program Files\dotnet\sdk]
2.1.508 [C:\Program Files\dotnet\sdk]
2.1.509 [C:\Program Files\dotnet\sdk]
2.1.511 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
2.1.604 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.1.802 [C:\Program Files\dotnet\sdk]
2.2.103 [C:\Program Files\dotnet\sdk]
2.2.202 [C:\Program Files\dotnet\sdk]
2.2.204 [C:\Program Files\dotnet\sdk]
2.2.300 [C:\Program Files\dotnet\sdk]
2.2.401 [C:\Program Files\dotnet\sdk]
2.2.402 [C:\Program Files\dotnet\sdk]
3.1.101 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
```

I think there's some weirdness with caching targets in VS so I dropped down to running dotnet build on the project a few times. If I focus on v2 only -- something breaks between 1.0.27 and 1.0.31 (I'll narrow it down). Can you confirm the same? Basically:

  1. Set Microsoft.Net.Sdk.Functions to 1.0.27, save.
  2. From cmd prompt, run dotnet build
  3. See if the http\function.json file is copied to bin\Debug\netcoreapp2.2

Repeat for 1.0.31

In my case, 1.0.27 works; 1.0.31 does not.

Okay I think I know the issue. https://github.com/Azure/azure-functions-vs-build-sdk/commit/101e4ced4fa5d489883a45bf28821df42064dd65#diff-735fb791a91a29461eb9dc138f6051a8.

We added a new command line argument, but didn't adjust the parsing of excludedFunctionNames to account (it should be looking at index 3 now). So when we clean the output path, it removes that folder (https://github.com/Azure/azure-functions-vs-build-sdk/blob/master/src/Microsoft.NET.Sdk.Functions.Generator/FunctionJsonConverter.cs#L282).

I'll assign this to the next sprint, and we'll need to take this in v3 as well.

@brettsam there was a reason I choose 1.0.27. I think 1.0.28&29 also should work. But then the problems started. Not these file-thingy problem but a few others. 1.0.31 did not work well for us. Mind that we are almost only F# on this codebase where we had these problems, even though the problem in this issue is recreateable in C# too.

Anyhow, thanx for your patience and helpfulness! Very much appreciated!

Actually moving this to the next sprint (I had assigned to the current sprint earlier).

This had to be pushed to sprint 72.

Work in progress. Moving to sprint 73.

So what is going here now?

@fabiocav @brettsam

@helgeu picking this up as part of triage. Will follow up with @brettsam to get an update.

Moving this to the sprint that it was actually closed in.

Was this page helpful?
0 / 5 - 0 ratings