Decompiler removes leading underscores from param names

[NeilMacMullen]

Bicep version 1.23.0

Describe the bug ARM templates associated with Visual Studio deployment projects (*.deployproj) have a couple of variables that point to the artefacts. These are typically defined like this

 "_artifactsLocation": {
      "type": "string"
    },
    "_artifactsLocationSasToken": {
      "type": "securestring"
    },

When decompiled the leading underscore is removed...

param artifactsLocation string

@secure()
param artifactsLocationSasToken string

This breaks the standard Deploy-AzureResourceGroup.ps1 script.

[alex-frankel]

Good find - we allow this in bicep, so we shouldn't change this when decompiling. Out of curiosity - are you using that script to stage non-template artifacts like a powershell script? Or is that only for staging linked templates?

[NeilMacMullen]

We have a bunch of VS deployproj projects which are useful in development (since they automatically build dependencies and feed artefact paths etc to the deploy-azureresourcegroup script. The development flow is...

• hack code .
• delete the resources for the project/resource group under development
• right click on deployproj and choose "Deploy"
• check all is running as expected
• repeat...

Those have been using ARM templates up to now but we're in the process of trying to standardise those and replace them with (much nicer!) BICEP. There are a couple of minor annoyances to this....

• The deployproj projects simply refuse to recognise BICEP as an alternative to template.json
• The deployproj projects aren't able to use templates from a non-local directory.

So we have a "stanard-deployment-types" folder that contains the BICEP files and a powershell script that....

• compiles all the BICEP files to json templates
• copies the json templates to the deployment project folders

The deployment project can therefore use a local copy of "standard_function_template.json" even though it was originally generated from BICEP.

It's a lot clunkier than I would like but understandable that the VS tooling is not quite there yet!

Hopefully that answers your questions?

[alex-frankel]

Got it. It looks like the bicep/template code does not need anything other than bicep/template code in order to execute. For example, you don't have a resource that requires a zip file or powershell script to be staged somewhere. The reason that is important is that some of the magic that deploy-azureresourcegroup script does is stage files to a storage account. Since you don't need that, you should be able to either deploy the bicep code directly with Az PowerShell or Az CLI, or by running bicep build as you are doing.

As you note, bicep doesn't have any VS support and VS workflows are not something I understand very well. @bmoore-msft do you have a better sense of what is the "right" way bicep should be integrated into VS?

[NeilMacMullen]

Since you don't need that, you should be able to either deploy the bicep code directly with Az PowerShell or Az CLI

Ah - just to be clear , we are deploying artefacts - the bicep templates contain a deployment resource like this..

resource site_MSDeploy 'Microsoft.Web/sites/extensions@2020-12-01' = {
  name: '${site.name}/MSDeploy'
  properties: {
    packageUri: '${_artifactsLocation}${deployPackageFolder}/${deployPackageFileName}${_artifactsLocationSasToken}'
    dbType: 'None'
    connectionString: ''
    setParameters: {
      'IIS Web Application Name': siteName
    }
  }
}

So the point of using VS to deploy the resource group is that we get

• code compiled and the website (or function) built into a package.zip artefact,
• then all the resources created
• then the package.zip deployed to the resource group

all as a single step with just a right-click/Deploy

[bmoore-msft]

re: VS - we probably need a project type to make it more elegant, I don't think it's a ton of work (assuming we wouldn't have things like the Add Resource Wizard to start) but it would remove the need for folks to create their own build steps.

[NeilMacMullen]

@bmoore-msft Actually what would be really nice would be to do away with the deployproj type entirely and just allow "Deploy" as an action on a function/webapp just as you can currently right-click and run "Publish". I realise the deployproj is probably unavoidable when there are mutiple buildable resource projects in the deployment but a lot of the time (at least for us) we're only deploying a single resource at a time.

[bmoore-msft]

I don't see any issue with that, but it only solve the problem for people using that type of project... If I have a SQL project or want to deploy to a VM it should work equally well there. As in the case where I don't want to deploy in VS at all.

[jbpaux]

I just got this bug today. I decompiled a json to make a bicep one and all _ were removed. I add them again, rebuild and it's ok but it should be solved or include in a "known issues". @alex-frankel I guess the error is here: https://github.com/Azure/bicep/blob/4e8f9982e29d3278eab6357e2817759ff0c857ce/src/Bicep.Decompiler/UniqueNamingResolver.cs#L36