Race condition in ExtensionsMetadataGenerator.targets leads to incorrect TargetDir

[TomBonnerAtTFL]

Investigative information

• Timestamp: As of 05 Feb 2019
• Function App version (1.0 or 2.0): 2.0
• Function App name: N/A
• Function name(s) (as appropriate): N/A
• Invocation ID: N/A
• Region: N/A

Repro steps

Referencing Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator should create an extensions.json file within our TargetDir. Currently, referencing both this, and Microsoft.Net.SDK.Functions leads to the incorrect TargetDir being used in the Generation part of this project.

Expected behavior

The file extensions.json should be generated in the correct TargetDir directory, with the correct values.

Actual behavior

A variety of things happen depending on the specific order of events, but most resolve into an empty extensions.json file being outputted somewhere.

Known workarounds

Putting a custom .targets file within your project.

Related information

I'm fairly sure this is the cause of a lot of issues given I believe (of course I could be wrong) this bug is referenced in the following:

• "No job functions found" after updating to 2.0.12050.0 Azure-Functions#928 (comment)
• Azure function Publish not creating Startup class entry in extensions.json Azure-Functions#972
• https://stackoverflow.com/questions/52583637/azure-function-publish-not-creating-startup-class-entry-in-extensions-json
• Functions using custom extensions work in emulator but fail indexing when deployed (c#, v2.0.12050.0) #3386
• Not working with Microsoft.Extensions.DependencyInjection v2.2.0 BorisWilhelms/azure-function-dependency-injection#26
• error "No job functions found" when trying to run functions locally chopeen/last-fm-not-mine-alert-func#5
• ExtensionsMetadataGenerator does not include function defined WebJobStartupAttribute azure-functions-core-tools#721
• extension.json not generating consistenly Azure-Functions#957

I have a pull-request which I'll attach shortly.

The issue is mostly caused by https://github.com/Azure/azure-functions-vs-build-sdk/blob/master/src/Microsoft.NET.Sdk.Functions.MSBuild/Targets/netstandard1.0/Microsoft.NET.Sdk.Functions.Build.targets#150 changing the TargetPath which (given the Property's in the current Extension.Targets are set at start) means that the ConsoleApp within ExtensionsMetadataGenerator executes over the wrong directory.

PS, my apologies for re-creating this, the original was under my personal GitHub account @moritonal

[TomBonnerAtTFL]

Okay, after a discussion on PR #4059 about the issue I'm at the point where I believe a fix is roughly the following:

• Update microsoft.net.sdk.functions\**\build\netstandard1.0ExtensionsMetadataGeneratorVersion.props and microsoft.net.sdk.functions\**\microsoft.net.sdk.functions.nuspec to version 1.0.2 (and try not to ask why it's hard-coded in a props file).
• Remove any hard-reference to Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator in your code (because otherwise this'll take priority and initiate too fast).

That's producing a solid extensions.json file on my machine and requires no consumer changes (although does require them to NOT reference metadata, which many people do under the belief it solved prior issues).

An update to ExtensionsMetadataGenerator to lazy evaluate the properties could fix some issues where it's directly referenced, but there are knock-on effects given ExtensionsMetadataGenerator has an odd _ResolveAdditionalReferenceCopyLocalPathsForFunctionsExtensions target that requires early evaluation. Albeit I havn't seen any use of it so far.

Share and Enjoy
Tom

[brettsam]

I've just released 1.0.25 to nuget: https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/1.0.25 which now updates everything to use ExtensionsMetadataGenerator 1.0.2 so this should now work. Please give that a try -- I'm pretty sure this addresses the issue here so I'm closing this issue.

However, the underlying "hardcoded version" issue isn't fixed. I've created Azure/azure-functions-vs-build-sdk#277 to track the fixing of this.

[brettsam]

And thank you @TomBonnerAtTFL for working through this with me! If you think this doesn't address everything, feel free to re-open this.