Add support for externally supplied worker extensions project

[jviau]

Issue describing the changes in this PR

resolves #2601
resolves #1252
resolves #1888
resolves #2125

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR -- TODO
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md -- TODO
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)

Additional information

This PR refactors the SDK to address multiple issues while introducing the ability to have the worker extension project externally supplied.

1. SDK targets now calculate the output path of the inner build by using msbuild target outputs.
   • FunctionsAssignTargetPaths was removed as we can no longer predict the paths that early in the build. Instead we calculate them all later on. This also addresses Regression in Microsoft.Azure.Functions.Worker.Sdk version 1.17.4/1.17.3 of solution builds using no-incremental #2601.
2. Externally supplying the extension project is now supported. This will address no-network builds and authenticated feed issues. To supply an external extension project follow these steps:
   1. Add the properties <FunctionsGenerateExtensionProject>false</FunctionsGenerateExtensionProject> and <ExtensionsCsProj>{{PATH OF EXTERNAL PROJECT}}</ExtensionsCsProj>
   2. Run dotnet build -t:GenerateExtensionProject on the function project. This will one-time generate the extension project to the ExtensionsCsProj path. It is then assumed that the generated project is checked into source control and included in solution files / build projects as necessary.
   3. Whenever making a change to the function apps reference closure, it is recommended to run dotnet build -t:GenerateExtensionProject again.
   4. IMPORTANT when providing an external extension project, this project is no longer kept up to date automatically. It is up to the user to re-run the GenerateExtensionProject target as necessary or to manually update webjobs extensions.

[pregress]

Can this be reviewed/merged ? Blocks .net 9 upgrades

[jviau]

@pregress how does this block .net9 upgrades for you?

[pregress]

@pregress how does this block .net9 upgrades for you?

#2601 (comment)

Can't upgrade what doesn't compile.

If you use the 1.17.2 version, which doesn't have the problem with dotnet 9 you get the following error:

.nuget/packages/microsoft.azure.functions.worker.sdk/1.17.2/build/Microsoft.Azure.Functions.Worker.Sdk.targets(64,9): error : Invalid combination of TargetFramework and AzureFunctionsVersion is set.

When you use version 1.17.3 or greater with dotnet 8 or 2.0.0 with dotnet 9 you get the following error:

Could not copy the file "/redacted/obj/Release/net9.0/linux-x64/extensions.json" because it was not found.

[pregress]

@fabiocav & @jviau could you provide an update on this?

[jcreek]

@fabiocav & @jviau is there a planned timescale on this?

[liliankasem]

lgtm, some minor comments/questions. I did not look through the .targets file changes yet

[liliankasem]

Is this a breaking change to introduce a required field to a public class?

[jviau]

I am not sure I consider this public API. It is a supporting task for our build targets, not expected to be used directly by customers.

[liliankasem]

Are there any new tests that can be written to validate this behaviour?