Updated the Repro Steps with a MINIMAL REPRO as well. If you want to view the comparison with Aspire 9.1, see the DETAILED REPRO.

@captainsafia fyi on this incoming issue related Function apps support.

@balachir can you confirm whether or not the end-to-end still works using the port that is shown in the dashboard? (7045 in this case) It is of course an issue we'd want to fix anyway but we are trying to understand if this is something that is only incorrect in the console logs to see if we should block 9.2 on this. Also, does this repro in non-VS scenarios?

FWIW, I believe @captainsafia just tried this locally in the CLI and it doesn't seem to repro for her.

@joperezr the end-to-end does not work with the port that is shown in the dashboard (7045 in this case). It only works if you use the port that is shown in the console logs (7071).

Using port 7045

Using port 7071

For whether it works with the CLI, I'll try that later today and get back to you.

@joperezr @captainsafia you're right. This does not reproduce for me if I try it using the CLI. Does it mean that this is a VS issue then?

cc: @v-elenafeng

Note: As described in my DETAILED REPRO in the Repro Steps above, even with VS 17.13, this issue only reproduces when the versions of Aspire.Hosting.AppHost and Aspire.Hosting.Azure.Functions are 9.2 and does not reproduce when the versions are 9.1.

Interesting, @captainsafia I believe you did mention that VS has their own way of launching hence this would suggest an issue on their side, but what is weird is that using the exact same VS but with 9.1 packages instead the issue does not repro. Any clue on why this may be happening?

@joperezr VS has its own implementation for how it launches the local Functions host when the user F5s that is independent of the Aspire implementation so I suspect something might've changed in that logic.

We might be able to narrow this down by testing with different VS versions but I am not sure what versions we have access to.

We might be able to narrow this down by testing with different VS versions but I am not sure what versions we have access to.

@captainsafia I have the required machines ready and have sent you a message in the Teams channel.

@captainsafia @sebastienros here are some more updates to this item based on my investigation today. I can get this to reproduce with both VS 17.13 and VS 17.14, but it does not reproduce using CLI.

Now, the interesting thing is that if I update only the Aspire.Hosting.AppHost package from 9.1.0 to 9.2.0, it still works fine. But as soon as I update the Aspire.Hosting.Azure.Functions package from 9.1.0-preview.1.25121.10 to 9.2.0-preview.1.25209.2, I can get this bug to repro when using VS. Hence, that seems to indicate that there's some change in Aspire.Hosting.Azure.Functions package in Aspire 9.2 that has made it incompatible with VS.

So far, I'm not aware of any easy workaround for this issue in VS other than falling back to Aspire 9.1.

@joperezr

I've just updated my solution to 9.2 and have the same issue, VS17.13.6,

Aspire.Hosting.Azure.Functions 9.2.0-preview.1.25209.2

If I roll the solution back to 9.1 it starts working again on the same VS version.

Just to add, it's not enough to roll back Aspire.Hosting.Azure.Functions, All of Aspire has to go back to 9.1

And now it's working, I have no idea why! No changes showing in source control, but it now works fine, listening on the correct port 🤷‍♂️

And now it's working, I have no idea why! No changes showing in source control, but it now works fine, listening on the correct port 🤷‍♂️

I'm finding that I can run from Visual Studio and get the error. Then, stop and run again and no error.

@JakeRadMSFT seems this is only broken when laucnhing from VS. Can you assign?

Looking at the diff v9.1.0...v9.2.0 I can see two changes that look related to the topic: #7789 and #7683 (though this appears to have been applied to 9.1 as well).

I'm also hitting issue's relating to this with the same port number.

In my case I noticed it because I've multiple function apps, but they are failing to start saying port 7071 is already in use (even though nothing is set to this port in launchsettings.json).

Is there any work around?

Looking at the diff v9.1.0...v9.2.0 I can see two changes that look related to the topic: #7789 and #7683 (though this appears to have been applied to 9.1 as well).

Yes, this is happening for me in both versions.

Running into similar issues with trying to get multiple functions running in aspire in v9.2, I think I saw something odd when pouring over the changes.

In #7789 file src/Aspire.Hosting.Azure.Functions/AzureFunctionsProjectResourceExtensions.cs
lines 176 and 180 don't seem to use the returned builder at all? Could that be the/a source of potential issue?
EDIT: Might not be an issue if it's just used for chaining convenience, sorry if that's a red herring.

Though I did seem to have success when keeping on v9.1-preview of the functions package.

EDIT: Upon further investigation, the issue I seem to be encountering on 9.2 is that the first azure function started up seems fine, but the second one fails to start and dies with the following logs (project names edited):

Working

2025-04-18T17:35:17.1172966Z Waiting for resource 'messaging' to enter the 'Running' state.
2025-04-18T17:35:17.1179297Z Waiting for resource 'TaskOne' to enter the 'Running' state.
2025-04-18T17:35:26.7228965Z Waiting for resource ready to execute for 'TaskOne'.
2025-04-18T17:35:26.7229123Z Waiting for resource 'messaging' to become healthy.
2025-04-18T17:35:52.8197671Z Waiting for resource ready to execute for 'messaging'.
2025-04-18T17:35:52.8199006Z Finished waiting for resource 'TaskOne'.
2025-04-18T17:35:52.8199370Z Finished waiting for resource 'messaging'.
2025-04-18T17:35:53.7340000Z 
2025-04-18T17:35:53.7350000Z Azure Functions Core Tools
2025-04-18T17:35:53.7370000Z Core Tools Version:       4.0.7030 Commit hash: N/A +bb4c949899cd5659d6bfe8b92cc923453a2e8f88 (64-bit)
2025-04-18T17:35:53.7380000Z Function Runtime Version: 4.1037.0.23568
2025-04-18T17:35:53.7390000Z 
2025-04-18T17:35:54.2470000Z [2025-04-18T17:35:54.241Z] Found C:\GitRepo\Project\src\FunctionAppOne\FunctionAppOne.csproj. Using for user secrets file configuration.
2025-04-18T17:35:54.3230000Z Skipping 'AzureWebJobsStorage' from local settings as it's already defined in current environment variables.
2025-04-18T17:35:54.3240000Z Skipping 'FUNCTIONS_WORKER_RUNTIME' from local settings as it's already defined in current environment variables.
2025-04-18T17:35:58.5400000Z [2025-04-18T17:35:58.539Z] Azure Functions .NET Worker (PID: 35060) initialized in debug mode. Waiting for debugger to attach...
2025-04-18T17:35:58.5930000Z [2025-04-18T17:35:58.591Z] Worker process started and initialized.
2025-04-18T17:35:58.7710000Z 
2025-04-18T17:35:58.7720000Z Functions:
2025-04-18T17:35:58.7730000Z 
2025-04-18T17:35:58.7740000Z 	TaskOneFunction: serviceBusTrigger
2025-04-18T17:35:58.7750000Z 
2025-04-18T17:35:58.7750000Z For detailed output, run func with --verbose flag.
2025-04-18T17:36:03.6230000Z [2025-04-18T17:36:03.621Z] Host lock lease acquired by instance ID '0000000000000000000000006299ABD8'.

Not working

2025-04-18T17:35:17.1001475Z Waiting for resource 'messaging' to enter the 'Running' state.
2025-04-18T17:35:17.1088988Z Waiting for resource 'TaskTwo' to enter the 'Running' state.
2025-04-18T17:35:26.7228965Z Waiting for resource ready to execute for 'TaskTwo'.
2025-04-18T17:35:26.7229135Z Waiting for resource 'messaging' to become healthy.
2025-04-18T17:35:52.8198639Z Waiting for resource ready to execute for 'messaging'.
2025-04-18T17:35:52.8199013Z Finished waiting for resource 'TaskTwo'.
2025-04-18T17:35:52.8199338Z Finished waiting for resource 'messaging'.
2025-04-18T17:35:53.7720000Z 
2025-04-18T17:35:53.7730000Z Azure Functions Core Tools
2025-04-18T17:35:53.7750000Z Core Tools Version:       4.0.7030 Commit hash: N/A +bb4c949899cd5659d6bfe8b92cc923453a2e8f88 (64-bit)
2025-04-18T17:35:53.7760000Z Function Runtime Version: 4.1037.0.23568
2025-04-18T17:35:53.7770000Z 
2025-04-18T17:35:54.2260000Z [2025-04-18T17:35:54.220Z] Found C:\GitRepo\Project\src\FunctionAppTwo\FunctionAppTwo.csproj. Using for user secrets file configuration.
2025-04-18T17:35:54.2930000Z Skipping 'AzureWebJobsStorage' from local settings as it's already defined in current environment variables.
2025-04-18T17:35:54.2950000Z Skipping 'FUNCTIONS_WORKER_RUNTIME' from local settings as it's already defined in current environment variables.
2025-04-18T17:35:58.6540000Z [2025-04-18T17:35:58.652Z] Azure Functions .NET Worker (PID: 33508) initialized in debug mode. Waiting for debugger to attach...
2025-04-18T17:35:58.7070000Z [2025-04-18T17:35:58.705Z] Worker process started and initialized.
2025-04-18T17:36:36.3000000Z Value cannot be null. (Parameter 'provider')

Lemme know if I should pull this into a separate issue.

Spent some time debugging this today, it appears that in 9.2, when DCP/AppHost invoke StartProjectAsync, the ProjectLaunchInfo.Arguments is null, whereas in 9.1, it is being set properly. This results in us using the default Functions port number (7071) when creating the launch arguments.

This is consistent with this change:

https://github.com/dotnet/aspire/pull/7789/files

@captainsafia

I have some additional information after further debugging, in the above referenced changes, it seems like the port is not null check below may be an issue.

            if (builder.ApplicationBuilder.ExecutionContext.IsPublishMode
              || port is not null)
            {
                return;
            }

If I rebuild this locally without the port is not null or skip over this in the debugger - things seem to work much better when a port is specified in the LaunchProfile,

When testing without the port specified in the launch profile, we still get two different generated ports in the dashboard and console log, but they both work, both for the landing page and the API itself.

Additionally, when specifying --useHttps in the launch profile with no port, I end up getting https: correctly in the dashboard, but it when the orchestrator evaluates endpoint reference expression, it doesn't take the scheme into account, as it launches the function app with http://.

Also note, that the dashboard https link does not work, but does if you change the scheme to http:

@danmoseley, based on the above, this seems like an issue with the Functions hosting package.

Removing Tooling Area and @phenning for now. Feel free to pull us back in :)

Thanks for these extra diagnostics that helps

@mitchdenny are you the owner of next action here? need assignee probably

I was looking at it but got side tracked with some blocking debugger attach issue.

@captainsafia can you take a look at this tomorrow?

I think we need to punt this to 9.4.

I tried reverting the changes that were made to the Functions hosting package in 9.1 and none of them resulted in the desired behavior. I suspect something else changed in Aspire that is causing the issue. That might also explain why the CTI team is only reporting that it doesn't repro if all the Aspire packages are downgraded.

As a workaround I've downgraded only Aspire.Hosting.Azure.Functions to 9.1.0-preview.1.25121.10. It now launches on the port I specified.

Other Aspire packages I left on 9.2.1.

i have also encountered issues when upgrading to 9.2. I am getting the error "Value cannot be null. (Parameter 'provider')" for any function apps in aspire that have an HTTP triggered function. I ensured all packages inside Visual Studio and nuget packages were installed.
Reverting to Aspire.Hosting.Azure.Functions to 9.1.0-preview.1.25121.10 also resolved the issue as a workaround for now

@DavidPotter01 Can you file a separate issue for this? The bug you're describing seems like it might be related to not defining a "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated" in your local.settings.json.

My local.settings.json did not change with this update
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "", "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated", ...
and reverting solved the issue