Updated versions for Azure.Provisioning and Azure.Provisioning.AppSer…

[ShilpiRach]

…vice packages

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

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
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13281

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13281"

[eerhardt]

@ArcturusZhang - is this change expected?

The code that is producing this is:

aspire/src/Aspire.Hosting.Azure.ServiceBus/AzureServiceBusExtensions.cs

Lines 49 to 51 in 02e5a10

	var resource = AzureProvisioning.ServiceBusNamespace.FromExisting(identifier);
	resource.Name = name;
	return resource;

and

aspire/src/Aspire.Hosting.Azure.ServiceBus/AzureServiceBusExtensions.cs

Lines 74 to 75 in 02e5a10

	// We need to output name to externalize role assignments.
	infrastructure.Add(new ProvisioningOutput("name", typeof(string)) { Value = serviceBusNamespace.Name });

so resource.Name is being set to a hard coded BicepValue<string>, and then the ProvisioningOutput's Value is being set to the serviceBusNamespace.Name, which was set above.

[ArcturusZhang]

So if we always want an expression, we now must call the ToBicepExpression() on the BicepValue instance.
Previously whether outputting a value or an expression is kind of based on an internal rule which varies from types, and the beta version made a unification on that rule.
Now - a IBicepValue instance will always spit out its literal value if it has a literal value, also always spit out its expression value if it is assigned with an expression.
I think here from the code you are sharing, and if to spit out whatever in the bicep value is your intention, this is expected.
And from the result, the new bicep should be identical with the original one.
But if your purpose here is to always reference the property, I suggest we add a ToBicepExpression invocation which makes you always get a messaging.name expression

[eerhardt]

@ArcturusZhang - is this expected? Is this going to cause any problems, for example, if there are capabilities on the resource, is this going to clear it?

[ArcturusZhang]

could you show me the code that builds this part?
We have a behavior change that previously we never write an empty array, now we write an empty array when the array was assigned explicitly (touched)

[ArcturusZhang]

And as far as I know, a resource written as this, would always override whatever we have on azure. Therefore the original bicep would also erase the capabilities property, making this bicep identical as before.

But as I said above, if you could share the code that outputting this, I could check if it is expected in your usage to write this empty array because it does not always write an empty array right now.

[eerhardt]

These came from

Azure/azure-sdk-for-net@41ee2f0