Re-execute envvar and arg callbacks when restarting resources

[JamesNK]

Description

When a resource is first started by DCP it applies envvar and arg settings based on values from callbacks. Restarting a resource now reuses the same code to apply values again.

Also in this PR is a refactor of how callbacks are executed and applied. They're moved to new methods and reused between containers and executables.

Fixes #5879

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

[JamesNK]

The isinitialized check isn’t needed anymore after the last dcp refactor. Resource is now initialized on every start

[davidfowl]

Need to rewrite this against my refactor #7360

[Copilot]

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (4)

src/Aspire.Hosting/Dcp/DcpExecutor.cs:1248

• The variable 'value' is cast to 'string' without checking if it is indeed a 'string'. This could potentially cause a runtime error. Ensure 'value' is a 'string' before casting.

var resolvedValue = value switch

src/Aspire.Hosting/Dcp/DcpExecutor.cs:1258

• The variable 'resolvedValue' is cast to 'string' without checking if it is indeed a 'string'. This could potentially cause a runtime error. Ensure 'resolvedValue' is a 'string' before casting.

specs.Add((string)resolvedValue);

src/Aspire.Hosting/Dcp/DcpExecutor.cs:1221

• [nitpick] The error message 'Failed to apply argument '{ConfigKey}'' should be more specific about which argument failed. Consider including the argument name or value in the message.

resourceLogger.LogCritical(ex, "Failed to apply argument '{ConfigKey}'. A dependency may have failed to start.", value);

src/Aspire.Hosting/Dcp/DcpExecutor.cs:1263

• [nitpick] The error message 'Failed to apply container runtime argument '{ConfigKey}'' should be more specific about which argument failed. Consider including the argument name or value in the message.

resourceLogger.LogCritical(ex, "Failed to apply container runtime argument '{ConfigKey}'. A dependency may have failed to start.", value);

[JamesNK]

@davidfowl Updated. Please take a look.

[karolz-ms]

Makes a lot of sense

[davidfowl]

Where are the conflicts??

[davidfowl]

Oh @adamint 's change 😄

[adamint]

😄

[JamesNK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[JamesNK]

Are these real test failures or no?

[davidfowl]

No, #7448