Breaking changes in generated modules due to AutoRest.PowerShell upgrade from v3 to v4

We're moving forward with using the new version of the code generation tool, AutoRest.PowerShell v4, to take advantage of the features offered by the latest version. The redesign of the generated code to support new user requirements in this version inevitably introduces some breaking changes.

Below, we list the potential breaking changes from the perspective of users that may occur when upgrading the code generation tool for Azure PowerShell modules.

Note

The breaking changes listed below may not apply universally to all generated modules. The occurrence of these breaking changes also depends on the specific configurations used when generating Azure PowerShell modules with AutoRest.PowerShell v4. For detailed information on which breaking changes may occur, please refer to the breaking change list for the specific module.

Identity Parameter Updates

Removed -IdentityType parameter and introduced clearer switches and parameters:

• -EnableSystemAssignedIdentity

  Default value: false. Must be explicitly added if a SystemAssigned Identity is required.

• -UserAssignedIdentity

  Type: array of id strings Accepts one or more User Assigned Managed Identities.

How to mitigate the impact of breaking changes

• Replace old -IdentityType values with explicit parameters:

  • SystemAssigned → -EnableSystemAssignedIdentity
  • UserAssigned → -UserAssignedIdentity, specifying the desired identity IDs
  • SystemAssigned,UserAssigned → use both -EnableSystemAssignedIdentity and -UserAssignedIdentity

• Replace any previously used parameters for User Assigned identities (such as -IdentityUserAssigned or other variations, regardless of type) with -UserAssignedIdentity, which accepts an array of strings.

All original functionality remains, but scripts must be updated to use the new explicit parameters. Refer to the cmdlet documentation for exact syntax and usage.

Removal of parameter sets

Certain complex or cumbersome parameter sets have been removed from the cmdlet. All existing functionality remains available, but users must now use the supported parameter combinations as documented.

How to mitigate the impact of breaking changes

Users should refer to the latest cmdlet documentation to ensure they are using supported parameter set combinations.

List replaces array in generated C# classes

We now generate collection-like properties as List instead of Array in the models. This is because List is dynamic that it allows appending/deleting elements, while Array is fixed-size hence difficult to edit.

How to mitigate the impact of breaking changes

• Use methods from List to replace methods from Array, for example: use count instead of Length to retrieve the number of elements
• Use the ToArray function if conversion to a fixed-size array is needed

Use primitive types for enum instead of struct

We used to generate a struct for enum to support tab completer for parameters. This design has been abandoned due to its limitation of only supporting enums with string type.

How to mitigate the impact of breaking changes

Generally, this change won't cause a breaking change for users. In modules generated by older versions, users typically use primitive types, and the generated struct includes a converter that transforms these primitive types into the struct. The only requirement for users is to avoid using Microsoft.Azure.PowerShell.Cmdlets.{module}.Support directly.

Breaking changes due to bug fixes

Removal of PassThru for certain cmdlets

PassThru is a switch parameter that we add to cmdlets that don't have outputs to enable the pipeline functionality. In AutoRest.PowerShell v3, PassThru was incorrectly added to some cmdlets that do have outputs. This is fixed in v4 and those extra PassThru parameters are removed.

How to mitigate the impact of breaking changes

Discontinue using the PassThru parameter for these cmdlets. Be careful that by doing so the output may change.

Removal of readonly parameters

If a property is marked "x-ms-mutability": ["read"] in the OpenAPI spec, it means it should only appear in the output but never as an input parameter. However, in AutoRest.PowerShell v3, such kind of readonly parameters were incorrectly generated for cmdlets.

How to mitigate the impact of breaking changes

It's safe to simply remove these Readonly parameters, as they're ignored by the service.