Skip to content

Fix func start dotnet-isolated extension loading when project has a custom OutputPath#4927

Open
Copilot wants to merge 2 commits intomainfrom
copilot/fix-func-start-load-context
Open

Fix func start dotnet-isolated extension loading when project has a custom OutputPath#4927
Copilot wants to merge 2 commits intomainfrom
copilot/fix-func-start-load-context

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented May 2, 2026

func start always built with dotnet build --output bin/output, overriding $(OutDir). The Functions SDK MSBuild targets that generate .azurefunctions use $(OutputPath) (not $(OutDir)), so on projects with a custom OutputPath the extensions landed in the project's original output directory rather than bin/output. The host ran from bin/output, found no .azurefunctions, reported DotnetIsolatedApp: False, and loaded no extensions.

Changes

  • DotnetHelpers.TryGetBuildOutputPathAsync (new): Runs dotnet msbuild -getProperty:OutputPath -restore:false to resolve the project's actual output directory. Returns null on any failure (unrestored project, no project file) so callers can fall back safely.

  • DotnetHelpers.BuildDotnetProject: Accepts null for outputPath; when null, omits --output and lets MSBuild use the project's own OutputPath.

  • DotnetHelpers.BuildAndChangeDirectory: New honorProjectOutputPath parameter (default false, no change for existing callers). When true, evaluates the project's OutputPath and builds without --output, then cds into it. Falls back to --output bin/output if evaluation fails.

  • StartHostAction.PreRunConditions: Passes honorProjectOutputPath: true — the only call site that needs the new behavior. func pack and func k8s are unaffected.

  • Unit test: TryGetBuildOutputPathAsync_ReturnsNull_WhenNoProjectFileExists covers the null-return path.

Pull request checklist

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

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • azfunc.pkgs.visualstudio.com
    • Triggering command: /usr/bin/dotnet dotnet build src/Cli/func/Azure.Functions.Cli.csproj -q (dns block)
    • Triggering command: /opt/hostedtoolcache/CodeQL/2.25.1/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp /opt/hostedtoolcache/CodeQL/2.25.1/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp (dns block)
    • Triggering command: /tmp/codeql-scratch-50c7d6e9ded3e5a4/dbs/csharp/working/.dotnet/dotnet /tmp/codeql-scratch-50c7d6e9ded3e5a4/dbs/csharp/working/.dotnet/dotnet restore --no-dependencies /home/REDACTED/work/azure-functions-core-tools/azure-functions-core-tools/Azure.Functions.Cli.sln --packages /tmp/codeql-scratch-50c7d6e9ded3e5a4/dbs/csharp/working/packages /p:DisableImplicitNuGetFallbackFolder=true --verbosity normal /p:TargetFrameworkRootPath=/tmp/codeql-scratch-50c7d6e9ded3e5a4/dbs/csharp/working/emptyFakeDotnetRoot /p:NetCoreTargetingPackRoot=/tmp/codeql-scratch-50c7d6e9ded3e5a4/dbs/csharp/working/emptyFakeDotnetRoot /p:AllowMissingPrunePackageData=true (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

When running func start from the project root, dotnet build was always
invoked with --output bin/output, which overrides $(OutDir) but can
leave the Functions SDK MSBuild targets writing .azurefunctions to the
original $(OutputPath) location. This causes the host to see
DotnetIsolatedApp: False and load extensions from the wrong path.

Changes:
- Add TryGetBuildOutputPathAsync to DotnetHelpers.cs: evaluates the
  project's OutputPath MSBuild property without running a full build
- Modify BuildDotnetProject to accept null outputPath, in which case
  it runs dotnet build without --output (uses the project's own path)
- Add honorProjectOutputPath parameter to BuildAndChangeDirectory:
  when true, uses the project's actual OutputPath and falls back to
  bin/output if evaluation fails
- Update StartHostAction.PreRunConditions to pass
  honorProjectOutputPath: true so func start respects custom OutputPath
- Add unit test for TryGetBuildOutputPathAsync null-project-file case

Agent-Logs-Url: https://github.com/Azure/azure-functions-core-tools/sessions/854e692e-04e3-41a1-90a5-01492d7aab54

Co-authored-by: liliankasem <2198905+liliankasem@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix func start command to load Function Extensions correctly Fix func start dotnet-isolated extension loading when project has a custom OutputPath May 2, 2026
Copilot AI requested a review from liliankasem May 2, 2026 00:35
@liliankasem liliankasem marked this pull request as ready for review May 4, 2026 18:17
@liliankasem liliankasem requested a review from a team as a code owner May 4, 2026 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

func start using incorrect "load context", not loading Function Extensions.

2 participants