Resource parameter naming inconsistent

Details of the scenario you tried and the problem that is occurring

Some resources uses 'Name', some use 'AdapterName', and some use 'InterfaceAlias'. Is there any chance this could be unified?

For example, DefaultGatewayAddress uses InterfaceAlias but NetworkAdapterAdvancedProperty uses NetworkAdapterName whereas NetworkAdapterLso uses Name. I believe that in all three cases they are referring to the same property of the network driver instance.

Verbose logs showing the problem

Suggested solution to the issue

Make 'InterfaceAlias' the parameter name for all resources, but add parameter aliases to resources that had differently-named parameters so that the change is non-breaking.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

Get-DscResource -Module NetworkingDsc  | Select Name,Properties | where {$_.Properties.Name -or $_.Properties.InterfaceAlias -or $_.Properties.NetworkAdapterName}

The operating system the target node is running

OsName : Microsoft Windows 10 Pro for Workstations
OsOperatingSystemSKU : 161
OsArchitecture : 64-bit
WindowsVersion : 2009
WindowsBuildLabEx : 19041.1.amd64fre.vb_release.191206-1406
OsLanguage : en-US
OsMuiLanguages : {en-US}

Version and build of PowerShell the target node is running

Name Value

PSVersion 5.1.19041.906
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.906
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

8.2.0 NetworkingDsc

Start by running the issue's Get-DscResource command against NetworkingDsc and compare the Name, AdapterName, InterfaceAlias, and NetworkAdapterName properties across the listed resources. Done means the relevant resources consistently expose InterfaceAlias while retaining aliases for prior parameter names without breaking existing configurations.