Release v0.1.8-preview

[jason-dou]

We're excited to announce the release of v0.1.8-preview! This version is exclusively available on the Microsoft Artifact Registry (MAR) and can be accessed using dynamic types. Please note that it requires a minimum Bicep version of 0.30.3. For more information on how to migrate to dynamic types, check out How to migrate to dynamic types. Quickstart templates are also updated with examples using Graph Bicep resources in v0.1.8-preview.

Important

Built-in types are deprecated and will be retired on January 24, 2025. Until the retirement date, built-in types, denoted by extension microsoftGraph, will coexist with the new dynamic types. Any Microsoft Graph Bicep type changes will only be available through new versions of the dynamic types.

What's changes

• Added isManagementRestricted property in [email protected] resource type

Issues fixed

• Fixed an issue with managing app role assignment for all principal types EntitlementGrant entry already exists #161

---

This discussion was created from the release Release v0.1.8-preview.

[slavizh]

@jason-dou is there a way of the version of the type inside the .bicep file? Being defined in bicepconfig.json and referenced in .bicep file could lead the to problem where end user can take the .bicep file modify its bicepconfig.json with incorrect version that was used to verify the .bicep template functionality. It really looks like the version of the extension should not be defined in bicepconfig.json .

[slavizh]

@anthony-c-martin great. Thanks! 3 weeks is fine.

[anthony-c-martin]

Just to set expectations, there is now a pretty extensive change freeze in effect for Azure services over the winter holiday period. We have a window at the beginning of December; I hope this'll be deployed then, but can't make any guarantees in case something unexpected happens. If we miss that window, then we're looking at starting the deployment in early January.

[dkershaw10]

Thanks for the heads up. I'll update all usage examples not to use the "_" character.

[slavizh]

that is fine.

[dkershaw10]

FYI - doc PR is in progress and should be published some time this week.

[dkershaw10]

@slavizh we can add doc examples of defining the version of the type inside the .bicep file too.

[slavizh]

@dkershaw10 awesome. May be advantages and disadvantages to both approaches would be helpful for some folks.

[dkershaw10]

@slavizh Please see updated topic here: https://learn.microsoft.com/graph/templates/how-to-dynamic-types. Hopefully this addresses your concerns.

[dkershaw10]

@anthony-c-martin @shenglong I was creating some new docs on dynamic types, per the conversation above and I have a question, because I don't have a way to test the scenario. cc: @jason-dou

So say I do this:

extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:<v1.0-version>' as graphV1_0
extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/beta:<beta-version>' as graphBeta

Other than generating the ARM template with the alias names, I don't see any real benefit to the as keyword for this scenario. The only scenario I could think of that might be valuable is differentiating between two type versions in Microsoft Graph v1.0 for example, like:

extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:<v1.0-version-1>' as graphV1_0_latest
extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:<v1.0-version-2>' as graphV1_0_older

// using latest
resource group 'graphV1_0_latest:Microsoft.Graph/[email protected]' existing = {
    uniqueName: groupName
}

// using an older version
resource app 'graphV1_0_older:Microsoft.Graph/[email protected]' existing = {
    uniqueName: appName
}

I can't fully test this because we only have the one type version for v1.0 at the moment.
Do you think that this should work?

Also IntelliSense isn't working properly when you try to use the fully-qualified type name.

[anthony-c-martin]

Other than generating the ARM template with the alias names, I don't see any real benefit to the as keyword for this scenario. The only scenario I could think of that might be valuable is differentiating between two type versions in Microsoft Graph v1.0 for example, like:

I think your analysis is correct here - it's there for completeness, but isn't something I'd expect to see much outside of some very niche use-cases.

1. Exactly the scenario you've called out - if trying to disambiguate between a type of the same name that's available in 2 different imported providers.
2. If the user wants to define symbols and avoid collisions. The graph extension has a pretty unique name, so probably less likely to run into here. But for example, if the user is using the az provider, and wanted to define a variable named az - they would have to alias the namespace import.
3. (really an extension of 2). Namespaces can declare functions (although not used by msgraph), so if for example the msgraph provider ever had a need for a function like lookupUser(<upn>), this would also be useful to disambiguate so you could do e.g. graphV1_0.lookupUser(...). This extends beyond wanting to import graph twice - it's conceivable that another namespace (e.g. az) could define a function of the same name.

[dkershaw10]

Howdy folks,

Just an update here on dynamic types. Here and in our public docs, we've asked folks to migrate to dynamic types (from using the built-in types). Additionally, there are warnings in both VS/VS Code and when deploying a template file, if you are still using built-in types.

The notices and warning indicate that built-in types will no longer work from January 24. However, we're pushing this date out by a little over a month (likely first week in March, or whenever the monthly Bicep release happens in March). We're doing this because we want to give you more time and we discovered some issues with dynamic types in some of our air-gapped clouds, as part of our final testing of national cloud support (which will be available soon).