Skip to content

Conversation

@liliankasem
Copy link
Member

@liliankasem liliankasem commented Nov 11, 2025

Issue describing the changes in this PR

resolves #4670

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)

Additional information

Additional PR information

@liliankasem liliankasem requested a review from a team as a code owner November 11, 2025 22:37
Copy link
Contributor

@mattchenderson mattchenderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving for CI testing, but not to merge.

@liliankasem liliankasem reopened this Nov 12, 2025
@liliankasem liliankasem marked this pull request as draft November 12, 2025 18:49
@liliankasem liliankasem marked this pull request as ready for review November 12, 2025 19:12
@jviau
Copy link
Contributor

jviau commented Nov 12, 2025

Probably work for a different PR, if at all. Determining TFM from core tools doesn't work when the function app is multi-targeted. This change is definitely an improvement, but it will have the same multi-target issue.

Is there a framework parameter for func cli? Should we add one? Or consider this area not supported and error out when TFM cannot be found?

Using dotnet run target does work here, as you can specify the TFM for it.

@liliankasem
Copy link
Member Author

Probably work for a different PR, if at all. Determining TFM from core tools doesn't work when the function app is multi-targeted. This change is definitely an improvement, but it will have the same multi-target issue.

Yeah I think support for multiple TFMs is a little rough at the moment. I can definitely add a check for TargetFrameworks and prompt the user for which of the TFMs they would like to use from that list.

The determine TFM method comes into play for something like --docker-only where you have already initialized the worker with a TFM i.e.

func init --worker-runtime dotnet-isolated --target-framework net10.0

But now you're like "I want docker too!"

func init --docker-only

In which case we will a) determine worker from local settings and b) determine tfm via this method

We could also add support for func init --docker-only --target-framework net10.0 but I don't want to break the scenario where you just do the docker param.

Is there a framework parameter for func cli? Should we add one? Or consider this area not supported and error out when TFM cannot be found?

Yeah there is already a tfm param for func init

--target-framework Initialize a project with the given target framework moniker. Currently supported only when --worker-runtime set to dotnet-isolated or dotnet. Options are - net10.0, net9.0, net8.0, net7.0, net6.0, net48

@liliankasem liliankasem changed the title Refactor DetermineTargetFramework to use msbuild Refactor DetermineTargetFramework to use msbuild & support multiple tfms Nov 12, 2025
@liliankasem liliankasem merged commit 430e782 into main Nov 13, 2025
37 checks passed
@liliankasem liliankasem deleted the liliankasem/test/dni-tfm-flakey branch November 13, 2025 23:29
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.

Flaky DotnetIsolatedInitTests E2E test

6 participants