The arm2pulumi converter always assumes that the resource group already exists and generates:

var resourceGroupVar = Output.Create(GetResourceGroup.InvokeAsync(new GetResourceGroupArgs
{
    ResourceGroupName = resourceGroupNameParam,
}));

However, if the developer wants resource group creation to be part of their Pulumi stack, the obvious code would be

var resourceGroupVar = new ResourceGroup(...);

The problem is that these return different types,

Output<GetResourceGroupResult>

and

ResourceGroup

, so if I wanted to switch from one to the other, all the other generated code results in errors because

Output.Apply()

isn't needed (or allowed) anymore. Looking closer, I determine that I can do this to avoid the errors.

var resourceGroupVar = Output.Create(new ResourceGroup(...));

But I'd only want to code it this way to avoid rewriting the converted code. I'd much prefer to treat all my resources the same (i.e. The return object is not of type

Output<T>

. To be more consistent, would it be possible to create

GetResourceGroup.Invoke()

that returned type

GetResourceGroupResult

.

Hey Dan. IIRC the arm2pulumi converter only generates the

invokeAsync

when location is not specified for resources in the arm templates and it tries to determine by querying the resource group. We are about to add support for inferring the default location from the resource group (i.e. fix https://github.com/pulumi/pulumi-azure-nextgen/issues/6 - should be in the next release) directly in the provider. In which case arm2pulumi would no longer generate the

invokeAsync

anymore and hopefully all other references can stick to the resource-group name instead. Are there other situations outside of location inference that the

invokeAsync

is being called for you?

I'm not sure that issue addresses this as the resource group location doesn't need to be present in ARM templates (we just use

resourcegroup().location

), but I'd be happy to require one in the config if it meant I could avoid

InvokeAsync

.

ah yes, sorry I missed the obvious

resourcegroup().location

use case - this will emit the

invokeAsync

. If you omit it in the arm template, invokeAsync will be avoided since the provider will take care of that resolution itself in the next release