Require resource group on existing azure resources

[eerhardt]

Since, by default, publishing a .NET Asipre app will create a new resource group, not specifying a resource group won't work - since the current resource group hasn't been created yet. Because of this, require callers to explicitly specify the resource group to use. They can still say null to mean "use the current" if that's really what they want.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
• Did you add public API?
  • No
• Does the change make any security assumptions or guarantees?
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • No
        • Link to aspire-docs issue (please use this doc-idea template):

[eerhardt]

Do we want to make the same change for the RunAsExisting methods? If someone specifies a Azure:ResourceGroup in their user secrets (and not a Prefix), the resource group can be existing. So it is more likely to work if you don't specify a resource group.

[eerhardt]

Given @mitchdenny's comment #7733 (comment), I think we should make the same change to RunAsExisting. It gives us room to take a single string to mean the whole resourceID in the future.

[mitchdenny]

Agreed

[eerhardt]

/backport to release/9.1

[github-actions]

Started backporting to release/9.1: https://github.com/dotnet/aspire/actions/runs/13465391305

[mitchdenny]

We can probably let this go in as is but have we considered using a fully qualified resource ID as well?

Given that scenario how would we disambiguate the APIs (since both would just be parameters).

[mitchdenny]

In case it wasn't obvious the reason for my question was around using existing resources that might be in a different sub which is actually pretty common.

[eerhardt]

We can probably let this go in as is but have we considered using a fully qualified resource ID as well?

I believe we talked about that orginally, but went with "resourceName" and "resourceGroup" separately.

Given that scenario how would we disambiguate the APIs (since both would just be parameters).

This change actually makes it easier becuase in the future we can add an overload that takes a single string which is the full resource ID. If we are going to do that, we should also make this same change to the RunAsExisting methods, so we can have the single string version in the future.

[eerhardt]

/backport to release/9.1

[github-actions]

Started backporting to release/9.1: https://github.com/dotnet/aspire/actions/runs/13465537766

[mitchdenny]

This change actually makes it easier becuase in the future we can add an overload that takes a single string which is the full resource ID. If we are going to do that, we should also make this same change to the RunAsExisting methods, so we can have the single string version in the future.

Very good point.