.NET Aspire - Missing BICEP files when using azd infra synth command

[PedroAlmeida21]

Describe the bug As part of my learning, I have a simple .NET Aspire application created from a template and I am trying to generate BICEP files for this application via Azure Developer CLI. In order to achieve that, I am running azd infra synth. Command works fine and no errors are displayed in the console. However, there are missing BICEP files which should be generated (see details below).

To Reproduce

1. Create .NET Aspire App

   dotnet new aspire-starter --use-redis-cache -o AspireAzdWalkthrough
   cd AspireAzdWalkthrough
   dotnet run --project AspireAzdWalkthrough.AppHost\AspireAzdWalkthrough.AppHost.csproj

2. Initialize the project

   azd init

3. Generate BICEP files

   azd config set alpha.infraSynth on
   azd infra synth

Expected behavior

• infra/main.bicep file is generated.
• infra/main.parameters.json file is generated.
• infra/resoures.bicep file is generated.
• AspireAzdWalkthrough.Web/manifests/containerApp.tmpl.yaml file is generated.
• AspireAzdWalkthrough.ApiService/manifests/containerApp.tmpl.yaml file is generated.

Observed behavior

• infra/main.bicep file is generated.
• infra/main.parameters.json file is generated.
• infra/resoures.bicep file is generated.
• AspireAzdWalkthrough.Web/manifests/containerApp.tmpl.yaml file is NOT generated.
• AspireAzdWalkthrough.ApiService/manifests/containerApp.tmpl.yaml file is NOT generated.

Environment Information on your environment:

• .NET Aspire (Preview)
• azd version 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96)
• .NET 8
• Microsoft Visual Studio Enterprise 2022 (64-bit) - Preview | Version 17.9.0 Preview 2.0

Additional context Probably I am missing something here, thus, please let me know if you need any additional information.

[rajeshkamal5050]

Interesting, not sure if there is anything related to your environment. Tried reproducing this and could see the container definition files being generated.

less AspireAzdWalkthrough.Web/manifests/containerApp.tmpl.yaml less AspireAzdWalkthrough.ApiService/manifests/containerApp.tmpl.yaml

Adding @ellismg. Any scenarios we skip this?

[ellismg]

Adding @ellismg. Any scenarios we skip this?

I don't believe so. We should be emitting a manifest for each project we see in the aspire manifest that we get from the apphost. I think the only reason we wouldn't generate these is if for some reason the apphost program no longer had calls to .AddProject?

You can see what was in the manifest by running

dotnet run --project AspireAzdWalkthrough.AppHost\AspireAzdWalkthrough.AppHost.csproj --publisher manfiest --output-path <path-to-some-file>

And then looking at the contents of the file that you passed to output-path above.

[PedroAlmeida21]

Hello @ellismg, I tried the same steps and BICEP files aren't still generated.

I ran your suggested command and got this as output:

{
  "resources": {
    "cache": {
      "type": "redis.v0"
    },
    "apiservice": {
      "type": "project.v0",
      "path": "../AspireAzdWalkthrough2.ApiService/AspireAzdWalkthrough2.ApiService.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "webfrontend": {
      "type": "project.v0",
      "path": "../AspireAzdWalkthrough2.Web/AspireAzdWalkthrough2.Web.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
        "ConnectionStrings__cache": "{cache.connectionString}",
        "services__apiservice__0": "{apiservice.bindings.http.url}",
        "services__apiservice__1": "{apiservice.bindings.https.url}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    }
  }
}

All resources are correctly identified. Worth mentioning that I used a template from Aspire without any modifications.

[BartNetJS]

I've got the same issue. Also ran the manifest generation and see also the correct result. Is there a way to generate it per project and copy it manually as a work around? I like to set for example the scaling rule to 0

[rajeshkamal5050]

@BartNetJS based on you updates/issues from another issue https://github.com/Azure/azure-dev/issues/3225 azd up works and infra resources get provisioned, apps/containers are getting deployed? i.e., in-memory infra generation is working(azd up does it as an implementation detail) fine but persisting to file-system(azf infra synth) is not?

@PedroAlmeida21 is it the same for you too?

cc @vhvb1989

[BartNetJS]

@rajeshkamal5050 with azd up, the infra gets provisioned, including the app container instance, but not the container apps, that is failing on the push to acr with a timeout. The azd infra synth does generate the infra folder with main.bicep, main.parameters and resources.bicep. But not the manifest files for the container apps as documented here :

[vhvb1989]

@BartNetJS @PedroAlmeida21 , can you share the debug logs by running azd infra synth --debug ?

[BartNetJS]

azd infra synth --debug 2024/01/29 11:19:25 main.go:54: azd version: 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96) 2024/01/29 11:19:25 main.go:208: using cached latest version: 1.5.1 (expires on: 2024-01-30T10:19:12Z) 2024/01/29 11:19:25 project.go:113: Reading project from file 'C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\azure.yaml' 2024/01/29 11:19:25 cobra_builder.go:141: Resolved action 'azd-infra-synth-action' 2024/01/29 11:19:25 middleware.go:124: running middleware 'debug' 2024/01/29 11:19:25 middleware.go:124: running middleware 'experimentation' 2024/01/29 11:19:25 experimentation.go:42: assignment context: 0g5ad841:76970; 2024/01/29 11:19:25 middleware.go:124: running middleware 'telemetry' 2024/01/29 11:19:25 telemetry.go:50: TraceID: b3e5bb0279006b97c9578c6989010b6b

WARNING: Feature 'infraSynth' is in alpha stage. To learn more about alpha features and their support, visit https://aka.ms/azd-feature-stages.

|= | Analyzing Aspire Application (this might take a moment...)2024/01/29 11:20:06 command_runner.go:307: Run exec: 'dotnet run --project TEST.DataEyesWH.AppHost.csproj --publisher manifest --output-path C:\Users\BartNetJS\AppData\Local\Temp\azd-provision660277999\apphost-manifest.json' , exit code: 0 -------------------------------------stdout------------------------------------------- Building... C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\EasyAuthAuthenticationBuilderExtensions.cs(49,13): warning CS0618: 'ISystemClock' is obsolete: 'Use TimeProvider instead.' [C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\TEST.DataEyesWH.Web.NoAuth.csproj] C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\EasyAuthAuthenticationBuilderExtensions.cs(50,13): warning CS0618: 'AuthenticationHandler.AuthenticationHandler(IOptionsMonitor, ILoggerFactory, UrlEncoder, ISystemClock)' is obsolete: 'ISystemClock is obsolete, use TimeProvider on AuthenticationSchemeOptions instead.' [C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\TEST.DataEyesWH.Web.NoAuth.csproj] C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\Components\Pages\Home.razor(13,22): warning CS8602: Dereference of a possibly null reference. [C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\TEST.DataEyesWH.Web.NoAuth.csproj] C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\Components\Pages\Home.razor(41,24): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. [C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\TEST.DataEyesWH.Web.NoAuth.csproj] C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\Components\Pages\Home.razor(31,29): warning CS8618: Non-nullable field 'user' must contain a non-null value when exiting constructor. Consider declaring the field as nullable. [C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\TEST.DataEyesWH.Web.NoAuth.csproj] C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\EasyAuthAuthenticationBuilderExtensions.cs(92,39): warning CS8600: Converting null literal or possible null value to non-nullable type. [C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH\TEST.DataEyesWH.Web.NoAuth\TEST.DataEyesWH.Web.NoAuth.csproj] info: Aspire.Hosting.Publishing.ManifestPublisher[0] Published manifest to: C:\Users\BartNetJS\AppData\Local\Temp\azd-provision660277999\apphost-manifest.json 2024/01/29 11:20:06 dotnet_importer.go:341: service webportal does not exist or has no bindings, ignoring value. 2024/01/29 11:20:06 dotnet_importer.go:341: service webfrontend does not exist or has no bindings, ignoring value. 2024/01/29 11:20:06 infra_synth.go:164: infrastructure synth, checking for duplicates. source: C:\Users\BartNetJS\AppData\Local\Temp\infra-synth1366174429 target: C:\Users\BartNetJS\sources\TEST.Aspire\TEST.DataEyesWH Warning: The following files would be overwritten by synthesized versions:

• infra\main.bicep
• infra\main.parameters.json
• infra\resources.bicep ? What would you like to do with these files? Overwrite with the synthesized versions

[vhvb1989]

@BartNetJS , by looking at the logs, it looks like there are configuration for the environment you are using that is not matching the generated manifest:

2024/01/29 11:20:06 dotnet_importer.go:341: service webportal does not exist or has no bindings, ignoring value.
2024/01/29 11:20:06 dotnet_importer.go:341: service webfrontend does not exist or has no bindings, ignoring value.

I wonder how you ended up in such situation. Did you make some changes to the dotnet project after dotnet new aspire-starter ?

It would really help if you could share the project from some repo.

[BartNetJS]

@vhvb1989 , yes indeed i played around and this was my workflow:

• added a new web project
• renamed builder.AddProject<...>("[gave it a new name]")
• commented out other web project(s)

So, indeed webfrontend and webportal are commented out in the appHost, but still exist as projects in the solution.

I've also created a new aspire project and didn't touched namings, etc, and then I don't have that warning, but still the manifest file per project is not generated (infra folder with main.bicep, main.parameters.json and resources.bicep are there)

The sample cna be found here: https://github.com/BartNetJS/aspire There is also a cli-steps-used.md where i copied all the cli commands i used with the logs.

Now I like to understand more in detail the dependencies between projects, the apphost hardcode name for the project like this builder.AddProject<...>("[can i change this ?]"), etc...

[davidfowl]

Where are you invoking infra synth from? The repo root?

[BartNetJS]

I tried from the root ./ and from ./AspireSample Twice with the same result. Infra folder and files are created, the project manifest files not:

[BartNetJS]

I'm also confused by the documentation. Here https://learn.microsoft.com/en-us/dotnet/aspire/deployment/manifest-format I see that the output format is json, and contains all services found in the AppHost.

Here https://learn.microsoft.com/en-us/dotnet/aspire/deployment/azure/aca-deployment-azd-in-depth?tabs=windows#generate-bicep-from-net-aspire-app-model

That azd infra synth generates containerApp.tmpl.yaml in yaml format and per project.

When i run azd infra synth --debug i see that the json file is create in the local user temp folder:

azd infra synth --debug
2024/02/01 09:35:54 main.go:54: azd version: 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96)
2024/02/01 09:35:54 main.go:208: using cached latest version: 1.5.1 (expires on: 2024-02-01T14:39:47Z)
2024/02/01 09:35:54 project.go:113: Reading project from file 'C:\Users\[userfolder]\sources\playground\aspire\azure.yaml'
2024/02/01 09:35:54 cobra_builder.go:141: Resolved action 'azd-infra-synth-action'
2024/02/01 09:35:54 middleware.go:124: running middleware 'debug'
2024/02/01 09:35:54 middleware.go:124: running middleware 'experimentation'
2024/02/01 09:35:54 experimentation.go:42: assignment context: 9936g960:76971;
2024/02/01 09:35:54 middleware.go:124: running middleware 'telemetry'
2024/02/01 09:35:54 telemetry.go:50: TraceID: 674c7b8438581ec1701faebe2a39f8d0

WARNING: Feature 'infraSynth' is in alpha stage.
To learn more about alpha features and their support, visit https://aka.ms/azd-feature-stages.

  |====== | Analyzing Aspire Application (this might take a moment...)2024/02/01 09:35:58 command_runner.go:307: Run exec: 'dotnet run --project AspireSample.AppHost.csproj --publisher manifest --output-path C:\Users\[userfolder]\AppData\Local\Temp\azd-provision2045899210\apphost-manifest.json' , exit code: 0
-------------------------------------stdout-------------------------------------------
Building...
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\Users\[userfolder]\AppData\Local\Temp\azd-provision2045899210\apphost-manifest.json
2024/02/01 09:35:58 infra_synth.go:164: infrastructure synth, checking for duplicates. source: C:\Users\BARTVA~1\AppData\Local\Temp\infra-synth503798419 target: C:\Users\[userfolder]\sources\playground\aspire

Do i understand it correct that the bicep files are generated by azd given the json output file from the manifest publisher?

[davidfowl]

Do i understand it correct that the bicep files are generated by azd given the json output file from the manifest publisher?

Correct, bicep and yaml files.

[BartNetJS]

I did a lot of testing. When I create a new aspire project, after running the azd infra synth, the bicep files for the projects where created. I noticed that the debug log doesn't log anything about the manifest creation. I also noticed that the bicep filles are created or recreated before the warning message to override the infra files of they already exist.

I also tested to copy my project files where the manifest initialy where not created to the 'working' solution. And then also the biceps files where generated.

I did then the opposite, copied the working project to the non working solution. And then the bicep files where not generated. I compared the differences in structure, but couldn't find any difference. Very strange.

Is there anything more I can help you to find the issue?

[davidfowl]

Multiple people are hitting this https://github.com/dotnet/aspire/discussions/2069#discussioncomment-8357095

[christiannagel]

My project is at https://github.com/PacktPublishing/Pragmatic-Microservices-with-CSharp-and-Azure, ch12 in the 12-scaling branch. Azure Cosmos DB, and App Insights resources are created first. azd up correctly publishes the Azure Container Apps for redis (container), gamesapi (project), and bot (project). Using azd infra synth creates the bicep files to create the registry, log analytics workspace, container app environment, and a container app for redis. The container apps for the projects are missing with the created bicep scripts.

Output of azd infra synth --debug

2024/02/04 10:16:15 main.go:54: azd version: 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96)
2024/02/04 10:16:15 project.go:113: Reading project from file 'D:\codebreaker\ch12\Pragmatic-Microservices-with-CSharp-and-Azure\ch12\Codebreaker.AppHost\azure.yaml'
2024/02/04 10:16:15 main.go:208: using cached latest version: 1.5.1 (expires on: 2024-02-04T15:31:36Z)
2024/02/04 10:16:15 cobra_builder.go:141: Resolved action 'azd-infra-synth-action'
2024/02/04 10:16:15 middleware.go:124: running middleware 'debug'
2024/02/04 10:16:15 middleware.go:124: running middleware 'experimentation'
2024/02/04 10:16:15 experimentation.go:42: assignment context: 0g5ad841:76970;
2024/02/04 10:16:15 middleware.go:124: running middleware 'telemetry'
2024/02/04 10:16:15 telemetry.go:50: TraceID: ab3f0a0d3def8278913d0932add9f6fd

WARNING: Feature 'infraSynth' is in alpha stage.
To learn more about alpha features and their support, visit https://aka.ms/azd-feature-stages.

  |====== | Analyzing Aspire Application (this might take a moment...)2024/02/04 10:16:22 command_runner.go:307: Run exec: 'dotnet run --project Codebreaker.AppHost.csproj --publisher manifest --output-path C:\Users\CHRIST~1\AppData\Local\Temp\azd-provision158015606\apphost-manifest.json' , exit code: 0
-------------------------------------stdout-------------------------------------------
Building...
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\Users\ChristianNagel\AppData\Local\Temp\azd-provision158015606\apphost-manifest.json
2024/02/04 10:16:22 infra_synth.go:164: infrastructure synth, checking for duplicates. source: C:\Users\CHRIST~1\AppData\Local\Temp\infra-synth2975305897 target: D:\codebreaker\ch12\Pragmatic-Microservices-with-CSharp-and-Azure\ch12\Codebreaker.AppHost

[weikanglim]

Hi @christiannagel @BartNetJS @PedroAlmeida21 , I reviewed the generation code and found an error unreported within the infra synth generation that could skip the manifest generation. Would you be willing to download the private build from https://github.com/Azure/azure-dev/pull/3295 and rerun infra synth --debug? The error will likely be reported with this change, then the next step is figure out how to address the error.

To install for Windows, run in pwsh:

powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3295/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3295/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3295' -Version '' -SkipVerify -Verbose;"

After install, run azd version, and it should print out as below:

$ azd version
azd version 1.5.1-pr.3469811 (commit 44277170ba55083b4ec7184b8bf2a4b695cc29a1)

Then run azd infra synth in the project.

[christiannagel]

@weikanglim, here is the result of azd infra synth --debug with this version. From the logs, it looked like it created temporary yml files for the projects, but finally there's no manifest folder within the project folders. As before, just the infra folder with bicep scripts only for the ACA with the redis container was created.

With this azd version, azd up fails as well. With version 1.5.1, azd up succeeded in creating the Azure resources.

azd infra synth --debug
2024/02/06 16:14:59 main.go:54: azd version: 1.5.1-pr.3469811 (commit 44277170ba55083b4ec7184b8bf2a4b695cc29a1)
2024/02/06 16:14:59 main.go:208: using cached latest version: 1.5.1 (expires on: 2024-02-06T17:05:49Z)
2024/02/06 16:14:59 project.go:113: Reading project from file 'D:\codebreaker\ch12\Pragmatic-Microservices-with-CSharp-and-Azure\ch12\Codebreaker.AppHost\azure.yaml'
2024/02/06 16:14:59 cobra_builder.go:141: Resolved action 'azd-infra-synth-action'
2024/02/06 16:14:59 middleware.go:124: running middleware 'debug'
2024/02/06 16:14:59 middleware.go:124: running middleware 'experimentation'
2024/02/06 16:14:59 experimentation.go:42: assignment context: 0g5ad841:76970;
2024/02/06 16:14:59 middleware.go:124: running middleware 'telemetry'
2024/02/06 16:14:59 telemetry.go:50: TraceID: b227a5dcca1c4dc8d48f95aef0386fb0

WARNING: Feature 'infraSynth' is in alpha stage.
To learn more about alpha features and their support, visit https://aka.ms/azd-feature-stages.

  |=======| Analyzing Aspire Application (this might take a moment...)2024/02/06 16:15:04 command_runner.go:307: Run exec: 'dotnet run --project Codebreaker.AppHost.csproj --publisher manifest --output-path C:\Users\CHRIST~1\AppData\Local\Temp\azd-provision2396516363\apphost-manifest.json' , exit code: 0
-------------------------------------stdout-------------------------------------------
Building...
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\Users\ChristianNagel\AppData\Local\Temp\azd-provision2396516363\apphost-manifest.json
2024/02/06 16:15:04 dotnet_importer.go:273: start writeManifestForResource: name:gameapis, path: D:/codebreaker/ch12/Pragmatic-Microservices-with-CSharp-and-Azure/ch12/Codebreaker.GameAPIs/Codebreaker.GameAPIs.csproj
2024/02/06 16:15:04 dotnet_importer.go:292: stop writeManifestForResource: name:gameapis, path: D:/codebreaker/ch12/Pragmatic-Microservices-with-CSharp-and-Azure/ch12/Codebreaker.GameAPIs/Codebreaker.GameAPIs.csproj
2024/02/06 16:15:04 dotnet_importer.go:273: start writeManifestForResource: name:bot, path: D:/codebreaker/ch12/Pragmatic-Microservices-with-CSharp-and-Azure/ch12/CodeBreaker.Bot/CodeBreaker.Bot.csproj
2024/02/06 16:15:04 dotnet_importer.go:292: stop writeManifestForResource: name:bot, path: D:/codebreaker/ch12/Pragmatic-Microservices-with-CSharp-and-Azure/ch12/CodeBreaker.Bot/CodeBreaker.Bot.csproj
2024/02/06 16:15:04 infra_synth.go:128: write to staging: ..\CodeBreaker.Bot\manifests\containerApp.tmpl.yaml
2024/02/06 16:15:04 infra_synth.go:128: write to staging: ..\Codebreaker.GameAPIs\manifests\containerApp.tmpl.yaml
2024/02/06 16:15:04 infra_synth.go:128: write to staging: infra\main.bicep
2024/02/06 16:15:04 infra_synth.go:128: write to staging: infra\main.parameters.json
2024/02/06 16:15:04 infra_synth.go:128: write to staging: infra\resources.bicep
2024/02/06 16:15:04 infra_synth.go:165: infrastructure synth, checking for duplicates. source: C:\Users\CHRIST~1\AppData\Local\Temp\infra-synth4088862743 target: D:\codebreaker\ch12\Pragmatic-Microservices-with-CSharp-and-Azure\ch12\Codebreaker.AppHost
2024/02/06 16:15:04 infra_synth.go:233: found staging file: C:\Users\CHRIST~1\AppData\Local\Temp\infra-synth4088862743\infra\main.bicep
2024/02/06 16:15:04 infra_synth.go:233: found staging file: C:\Users\CHRIST~1\AppData\Local\Temp\infra-synth4088862743\infra\main.parameters.json
2024/02/06 16:15:04 infra_synth.go:233: found staging file: C:\Users\CHRIST~1\AppData\Local\Temp\infra-synth4088862743\infra\resources.bicep
WARNING: your version of azd is out of date, you have 1.5.1-pr.3469811 and the latest version is 1.5.1

To update to the latest version, run:
powershell -ex AllSigned -c "Invoke-RestMethod 'https://aka.ms/install-azd.ps1' | Invoke-Expression"

If the install script was run with custom parameters, ensure that the same parameters are used for the upgrade. For advanced install instructions, see: https://aka.ms/azd/upgrade/windows

[weikanglim]

@christiannagel That was quite illuminating! From the logs, I believe the issue is due to azure.yaml is being created in the AppHost project directory instead of the solution directory (one directory above the AppHost and other projects).

To workaround this, I would:

1. Move existing azure.yaml from AppHost/azure.yaml one directory up to azure.yaml. Then, rename the project path inside azure.yaml to point to AppHost/AppHost.csproj.
2. For future projects, run azd init in the directory above AppHost.

In the meantime, we'll think about how we can better handle or prevent this in the future.

[vhvb1989]

related: https://github.com/Azure/azure-dev/issues/3034

[christiannagel]

@weikanglim thanks! This created the bicep scripts now!

[BartNetJS]

@weikanglim

Here is my result of the azd infra synth --debug The logs shows write to staging: ..\..\..\..\BARTVA~1\sources\ApplicationPortal\TEST\TEST.ApiService\manifests\containerApp.tmpl.yaml is But the file is not there.

This is the log:

azd infra synth --debug
2024/02/07 08:52:14 main.go:54: azd version: 1.5.1-pr.3469811 (commit 44277170ba55083b4ec7184b8bf2a4b695cc29a1)
2024/02/07 08:52:14 main.go:208: using cached latest version: 1.5.1 (expires on: 2024-02-08T07:41:37Z)
2024/02/07 08:52:14 project.go:113: Reading project from file 'C:\Users\BartVanderAuweraert\sources\ApplicationPortal\TEST\azure.yaml'
2024/02/07 08:52:14 cobra_builder.go:141: Resolved action 'azd-infra-synth-action'
2024/02/07 08:52:14 middleware.go:124: running middleware 'debug'
2024/02/07 08:52:14 middleware.go:124: running middleware 'experimentation'
2024/02/07 08:52:14 experimentation.go:42: assignment context: 9936g960:76971;
2024/02/07 08:52:14 middleware.go:124: running middleware 'telemetry'
2024/02/07 08:52:14 telemetry.go:50: TraceID: e8645fc9f576caa2dd112236aba6ca56

WARNING: Feature 'infraSynth' is in alpha stage.
To learn more about alpha features and their support, visit https://aka.ms/azd-feature-stages.

  |=      | Analyzing Aspire Application (this might take a moment...)2024/02/07 08:52:20 command_runner.go:307: Run exec: 'dotnet run --project TEST.AppHost.csproj --publisher manifest --output-path C:\Users\BARTVA~1\AppData\Local\Temp\azd-provision2868993720\apphost-manifest.json' , exit code: 0
-------------------------------------stdout-------------------------------------------
Building...
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\Users\BartVanderAuweraert\AppData\Local\Temp\azd-provision2868993720\apphost-manifest.json
2024/02/07 08:52:20 dotnet_importer.go:273: start writeManifestForResource: name:apiservice, path: C:\Users\BARTVA~1\sources\ApplicationPortal\TEST\TEST.ApiService\TEST.ApiService.csproj
2024/02/07 08:52:20 dotnet_importer.go:292: stop writeManifestForResource: name:apiservice, path: C:\Users\BARTVA~1\sources\ApplicationPortal\TEST\TEST.ApiService\TEST.ApiService.csproj
2024/02/07 08:52:20 dotnet_importer.go:273: start writeManifestForResource: name:webfrontend, path: C:\Users\BARTVA~1\sources\ApplicationPortal\TEST\TEST.Web\TEST.Web.csproj
2024/02/07 08:52:20 dotnet_importer.go:292: stop writeManifestForResource: name:webfrontend, path: C:\Users\BARTVA~1\sources\ApplicationPortal\TEST\TEST.Web\TEST.Web.csproj
2024/02/07 08:52:20 infra_synth.go:128: write to staging: ..\..\..\..\BARTVA~1\sources\ApplicationPortal\TEST\TEST.ApiService\manifests\containerApp.tmpl.yaml
2024/02/07 08:52:20 infra_synth.go:128: write to staging: ..\..\..\..\BARTVA~1\sources\ApplicationPortal\TEST\TEST.Web\manifests\containerApp.tmpl.yaml
2024/02/07 08:52:20 infra_synth.go:128: write to staging: infra\main.bicep
2024/02/07 08:52:20 infra_synth.go:128: write to staging: infra\main.parameters.json
2024/02/07 08:52:20 infra_synth.go:128: write to staging: infra\resources.bicep
2024/02/07 08:52:20 infra_synth.go:165: infrastructure synth, checking for duplicates. source: C:\Users\BARTVA~1\AppData\Local\Temp\infra-synth1320258805 target: C:\Users\BartVanderAuweraert\sources\ApplicationPortal\TEST
2024/02/07 08:52:20 infra_synth.go:233: found staging file: C:\Users\BARTVA~1\AppData\Local\Temp\infra-synth1320258805\infra\main.bicep
2024/02/07 08:52:20 infra_synth.go:233: found staging file: C:\Users\BARTVA~1\AppData\Local\Temp\infra-synth1320258805\infra\main.parameters.json
2024/02/07 08:52:20 infra_synth.go:233: found staging file: C:\Users\BARTVA~1\AppData\Local\Temp\infra-synth1320258805\infra\resources.bicep
  Warning: The following files would be overwritten by synthesized versions:
 * infra\main.bicep
 * infra\main.parameters.json
 * infra\resources.bicep
? What would you like to do with these files? Overwrite with the synthesized versions
WARNING: your version of azd is out of date, you have 1.5.1-pr.3469811 and the latest version is 1.5.1

[davidfowl]

@BartNetJS can you show you directory layout and where azure.yaml is?

[BartNetJS]

@davidfowl hereby the layout:

[weikanglim]

@BartNetJS Apologies for this. It looks like azd isn't handling the case where the directory is aliased to a "short filename" ending in ~1. I'll need to dig in deeper and figure out if there's some hardening to do here.

In the meantime, if it's something that works for you, I believe moving the entire solution directory out of C:\Users\<your home dir> to something like C:\sources would workaround the issue.

[paule96]

Following comment was tested on Windows and Linux

@weikanglim I guess the bug is back again. Currently, I facing the same falling behavior.

So I followed the steps of the tutorial here.

I just created the sample model and did run the azd init and just selected the web frontend as an exposed service

Then I did run the azd infra synth --force --debug. The log output is the following:

PS D:\labs\aspireazdbug\AspireSample> azd infra synth --force --debug
2024/03/19 14:03:09 main.go:59: azd version: 1.7.0 (commit 49d6adc2efb178083f61822e6b4715258560803d)
2024/03/19 14:03:09 main.go:229: using cached latest version: 1.7.0 (expires on: 2024-03-20T12:22:20Z)
2024/03/19 14:03:09 project.go:120: Reading project from file 'D:\labs\aspireazdbug\AspireSample\azure.yaml'
2024/03/19 14:03:09 project.go:120: Reading project from file 'D:\labs\aspireazdbug\AspireSample\azure.yaml'
2024/03/19 14:03:09 middleware.go:106: running middleware 'debug'
2024/03/19 14:03:09 middleware.go:106: running middleware 'experimentation'
2024/03/19 14:03:09 experimentation.go:42: assignment context: 0g5ad841:76970;
2024/03/19 14:03:09 middleware.go:106: running middleware 'telemetry'
2024/03/19 14:03:09 telemetry.go:38: TraceID: e7f27837816fdf72eb39e46dc87f7ce4

WARNING: Feature 'infraSynth' is in alpha stage.
To learn more about alpha features and their support, visit https://aka.ms/azd-feature-stages.

  | ======| Analyzing Aspire Application (this might take a moment...)2024/03/19 14:03:11 command_runner.go:307: Run exec: 'dotnet run --project AspireSample.AppHost.csproj --publisher manifest --output-path C:\Users\pjeschke\AppData\Local\Temp\azd-provision918598242\apphost-manifest.json' , exit code: 0
-------------------------------------stdout-------------------------------------------
Building...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.0.0-preview.4.24156.9+692dc41a65da572a7df25d53a9f2880afe59fdd8
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\Users\pjeschke\AppData\Local\Temp\azd-provision918598242\apphost-manifest.json

If I now look into the folder structure I see the following files:

But as you can see there are no *.tmpl.yaml files. So if nothing else did change I guess it's broken again.

For better debugging I add the relevant azd files here.

• environment config.json
• config.json
• main.parameters.json

azure.yaml (not allowed to upload to github):

# yaml-language-server: $schema=https://raw.githubusercontent.com/Azure/azure-dev/main/schemas/v1.0/azure.yaml.json

name: AspireSample
services:  
  app:
    language: dotnet
    project: .\AspireSample.AppHost\AspireSample.AppHost.csproj
    host: containerapp

main.bicep:

targetScope = 'subscription'

@minLength(1)
@maxLength(64)
@description('Name of the environment that can be used as part of naming resource convention, the name of the resource group for your application will use this name, prefixed with rg-')
param environmentName string

@minLength(1)
@description('The location used for all deployed resources')
param location string

var tags = {
  'azd-env-name': environmentName
}

resource rg 'Microsoft.Resources/resourceGroups@2022-09-01' = {
  name: 'rg-${environmentName}'
  location: location
  tags: tags
}

module resources 'resources.bicep' = {
  scope: rg
  name: 'resources'
  params: {
    location: location
    tags: tags
  }
}

output MANAGED_IDENTITY_CLIENT_ID string = resources.outputs.MANAGED_IDENTITY_CLIENT_ID
output MANAGED_IDENTITY_NAME string = resources.outputs.MANAGED_IDENTITY_NAME
output AZURE_LOG_ANALYTICS_WORKSPACE_NAME string = resources.outputs.AZURE_LOG_ANALYTICS_WORKSPACE_NAME
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = resources.outputs.AZURE_CONTAINER_REGISTRY_ENDPOINT
output AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID string = resources.outputs.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID
output AZURE_CONTAINER_APPS_ENVIRONMENT_ID string = resources.outputs.AZURE_CONTAINER_APPS_ENVIRONMENT_ID
output AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN string = resources.outputs.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN

resources.bicep:

@description('The location used for all deployed resources')
param location string = resourceGroup().location

@description('Tags that will be applied to all resources')
param tags object = {}

var resourceToken = uniqueString(resourceGroup().id)

resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: 'mi-${resourceToken}'
  location: location
  tags: tags
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-07-01' = {
  name: replace('acr-${resourceToken}', '-', '')
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
  tags: tags
}

resource caeMiRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(containerRegistry.id, managedIdentity.id, subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d'))
  scope: containerRegistry
  properties: {
    principalId: managedIdentity.properties.principalId
    principalType: 'ServicePrincipal'
    roleDefinitionId:  subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d')
  }
}

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: 'law-${resourceToken}'
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
  tags: tags
}

resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2023-05-01' = {
  name: 'cae-${resourceToken}'
  location: location
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspace.properties.customerId
        sharedKey: logAnalyticsWorkspace.listKeys().primarySharedKey
      }
    }
  }
  tags: tags
}

resource cache 'Microsoft.App/containerApps@2023-05-02-preview' = {
  name: 'cache'
  location: location
  properties: {
    environmentId: containerAppEnvironment.id
    configuration: {
      activeRevisionsMode: 'Single'
      ingress: {
        external: false
        targetPort: 6379
        transport: 'tcp'
      }
    }
    template: {
      containers: [
        {
          image: 'redis:7.2.4'
          name: 'cache'
        }
      ]
      scale: {
        minReplicas: 1
      }
    }
  }
  tags: union(tags, {'aspire-resource-name': 'cache'})
}

output MANAGED_IDENTITY_CLIENT_ID string = managedIdentity.properties.clientId
output MANAGED_IDENTITY_NAME string = managedIdentity.name
output MANAGED_IDENTITY_PRINCIPAL_ID string = managedIdentity.properties.principalId
output AZURE_LOG_ANALYTICS_WORKSPACE_NAME string = logAnalyticsWorkspace.name
output AZURE_LOG_ANALYTICS_WORKSPACE_ID string = logAnalyticsWorkspace.id
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = containerRegistry.properties.loginServer
output AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID string = managedIdentity.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_ID string = containerAppEnvironment.id
output AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN string = containerAppEnvironment.properties.defaultDomain

[paule96]

After cloning the repo and debug by myself a bit the current research is the following:

• the tmp directory is created as expected
• The lines that copy the code just skip the templates

[paule96]

@weikanglim after debugging the CLI I saw I look at the wrong places... It's important that the template files for the container apps are generated in the project folders itself and not under ./infra