azd vs-server should support not-just-Aspire scenarios

[bradygaster]

We'd like to investigate being able to call azd from VS in ways unrelated to Aspire but atm, the integration relies on the presence of an App Host. We wouldn't want any new magic invented; the implication is, we'd like to enable folks to be able to use azd to deploy from within VS like they can for Aspire apps, if their projects are already dialed-up with azd.

Tasks:

• Handle non-Aspire projects that are non-fully qualified, i.e. ./MyProject that contains both csproj and solution
• Handle resource-group scoped deployments

[weikanglim]

This makes sense.

I made a draft implementation of what these set of changes could look like: #5536

One immediate question -- What type of language project files would we imagine to support inside VS? Currently, the app host project is the launching point for the current VS experience.

It's possible that design choices will have to evolve over time around the fact that in Aspire, the target is the app host project -- here the target is likely a single project that participates within an azd project (there could be multiple).

Happy to chat more about it offline or over here.

[anvillan]

@weikanglim

With the linked PR's installable, I tried running VS IDE Azd Deployment scenarios using a azd'ed Web Project and this is what I found:

1. azd-vs-server starts, but it fails to find the Aspire Host project: the failure occurs when dotnet msbuild command runs:

8/1/2025 2:50:48 PM: Error failed to find Aspire app host: error checking if C:\Users\anvillan\source\repos\AzdAppService is an app host project: running dotnet msbuild on project 'C:\Users\anvillan\source\repos\AzdAppService': exit code: 1, stdout: MSBUILD : error MSB1063: Cannot access properties or items when building solution files or solution filter files. This feature is only available when building individual projects.
Switch: getProperty

The actual command is dotnet msbuild <path> --getProperty:IsAspireHost --getItem:ProjectCapability.

Here:

azure-dev/cli/azd/pkg/tools/dotnet/dotnet.go

Line 310 in 4836a9f

runArgs := newDotNetRunArgs("msbuild", projectPath, "--getProperty:IsAspireHost", "--getItem:ProjectCapability")

The <path> in the command is the Solution root folder, as that is set to the current_working_directory (cwd) for an Aspire project.

2. Setting the <path> to the project file (.csproj) path makes the command succeeds (manually tested it). E.g.:

dotnet msbuild "C:\Users\anvillan\source\repos\AzdAppService\BasicNewRazorApp.csproj" --getProperty:IsAspireHost --getItem:ProjectCapability

3. However, changing the VS code to set the cwd path as in (2) breaks the server at startup with the following failure:

8/4/2025 2:32:34 PM: Error Error: failed to change directory to C:\Users\anvillan\Source\Repos\AzdAppService\BasicNewRazorApp.csproj: chdir C:\Users\anvillan\Source\Repos\AzdAppService\BasicNewRazorApp.csproj: The directory name is invalid.

Here:

azure-dev/cli/azd/cmd/root.go

Line 72 in 4836a9f

return fmt.Errorf("failed to change directory to %s: %w", opts.Cwd, err)

So, it seems that azd-vs-server needs some adjustments so I can correctly take the cwd for a Web Project.

Let me know so what changes would be necessary from VS IDE side.

CC: @bradygaster @rajeshkamal5050

[weikanglim]

Hi @anvillan

If I'm reading the repro right, there's probably both file(s) existing:

• C:\Users\anvillan\source\repos\AzdAppService\BasicNewAppRazorApp.sln
• C:\Users\anvillan\source\repos\AzdAppService\BasicNewAppRazorApp.csproj

In this case, the msbuild command would fail.

In azure.yaml (whereever it may be located), if we change:

services:
  app:
    project: ./AzdAppService

into

services:
  app:
    project: ./AzdAppService/BasicNewAppRazorApp.csproj

It might work.

I have to think a little more about how we should handle this in azd. This has been the existing behavior, and in previous cases, azd would consider the project as "non-App host" -- but this switch is critical for us here when we're trying to differentiate an AppHost project from a standard dotnet project.

[anvillan]

@weikanglim

Thanks for the explanation. I can experiment with azure.yaml file, using the different paths and see how it goes.

Let you know any findings.

[anvillan]

@weikanglim

I experimented with the latest bits of this PR and this is what I see:

• Your assumption is correct: the BasicNewAppRazorApp.sln and BasicNewAppRazorApp.csproj files, both exists in the root of the project folder.
• After updating ./azure.yaml with "project: ./BasicNewRazorApp.csproj", the azd-vs_server starts correctly
• By "hacking" the VS IDE code, Environments can be created and "listed"

However, while loading a specific environment, a /prompt request is sent from theazd-vs_server, but it seems "incomplete":

{
    "type":"select",
    "options":{
        "message":"Pick a resource group to use:",
        "help":"",
        "choices":[
            {"value":"1. Create a new resource group"},
            {"value":"2. group1"},
            {"value":"3. group2"},
            ...
            {"value":"13. group_n"}
        ]
    }
}

The rest of the elements of the request (description, callerId, prompts) are not included.

This causes that, from VS, we pop up the dialog for the request, but it only contains the Title (as that is the only data). That makes it not actionable, and the server fails with "8/11/2025 10:20:39 AM: Error initializing provisioning manager: selecting resource group: unexpected result: "

CC: @bradygaster

[weikanglim]

@anvillan Thanks for helping push this along!

I suspect that for this particular project, the Bicep is leveraging resource-group scoped deployments, i.e., under ./infra/main.bicep:

targetScope = 'resourceGroup'

Which is different than traditional Aspire:

targetScope = 'subscription'

If it helps move things further along -- you may replace it with targetScope = 'subscription' for now. This may also require some small Bicep changes that I believe CoPilot will be able to help nicely.

On the scenario here related to the resource group prompt:

I'm slowly remembering now that azd cli supports many different kinds of "rich selection" prompting for infra related parameters that isn't supported in VS today (Aspire doesn't leverage these features).

For example, in this selecting a resource group prompt -- if running natively in the CLI, and the user were to pick "Create a new resource group", azd would present another prompt, before finally executing on an ad-hoc Azure resource group creation. This wouldn't be directly compatible with our current dialog design without further investment. FYI @bradygaster

[anvillan]

@weikanglim

I tried modifying the main.bicep file without success:

• targetScope was not defined already, so I added it.
• Setting targetScope = 'resourceGroup' did not have any effect (same as if not added)
• Setting targetScope = 'subscription' resulted in a BICEP error while loading the environment:

8/12/2025 2:53:51 PM: Error initializing provisioning manager: selecting resource group: unexpected result: 
8/12/2025 2:54:30 PM: Error initializing provisioning manager: failed to compile bicep template: failed running bicep build: exit code: 1, stdout: , stderr: C:\Users\anvillan\source\repos\AzdAppService\infra\main.bicep(4,38) : Error BCP071: Expected 1 to 2 arguments, but got 0. [https://aka.ms/bicep/core-diagnostics#BCP071]
C:\Users\anvillan\source\repos\AzdAppService\infra\main.bicep(10,75) : Error BCP071: Expected 1 to 2 arguments, but got 0. [https://aka.ms/bicep/core-diagnostics#BCP071]
C:\Users\anvillan\source\repos\AzdAppService\infra\main.bicep(22,90) : Error BCP135: Scope "subscription" is not valid for this resource type. Permitted scopes: "resourceGroup". [https://aka.ms/bicep/core-diagnostics#BCP135]
C:\Users\anvillan\source\repos\AzdAppService\infra\main.bicep(29,66) : Error BCP135: Scope "subscription" is not valid for this resource type. Permitted scopes: "resourceGroup". [https://aka.ms/bicep/core-diagnostics#BCP135]
C:\Users\anvillan\source\repos\AzdAppService\infra\main.bicep(46,52) : Error BCP135: Scope "subscription" is not valid for this resource type. Permitted scopes: "resourceGroup". [https://aka.ms/bicep/core-diagnostics#BCP135]
C:\Users\anvillan\source\repos\AzdAppService\infra\main.bicep(85,48) : Error BCP071: Expected 1 to 2 arguments, but got 0. [https://aka.ms/bicep/core-diagnostics#BCP071]

I'd say I added the line in the right spot. Though, if necessary, we could take a look together.

Another thing I tried was to hack the code so the "Set Azure Provisioning Settings" operation could be done against the project. When done on an Aspire project, we save (in the user's secrets) the default subscription, location and resource group values that should be used for provisioning. I'm not completely sure how azd use this, though doing it for this test project had no effect (I was expecting that the /promp request was not going to be sent).

About the /prompt request(s):
Yes, as part of the Aspire-VS IDE work, we (VS) expose an HTTP service that listen for requests. One type of request it responds is the /prompt request, which contains data, parsed from the IDE side, to present a dialog to select/input information.

For Aspire deployment, this is the first time I see a request sent "in the middle" of managing an Environment or try to run a publish operation.

CC: @bradygaster

[rajeshkamal5050]

Thanks for moving this along @weikanglim @anvillan

@weikanglim please take a look at the updates above.

cc @kristenwomack @bradygaster