Resource parameter naming inconsistent

[gaelicWizard]

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

[PlagueHO]

Hi @gaelicWizard - this is a good point and agree that we should align the name of this parameter throughout. However, I don't think we can use Alias' here because the MOF doesn't allow for aliases. So, the only way to implement this would be as a breaking change.

This would be a significant breaking change as it would impact many different resources as you mention. Do you have a proposal of what name should be adopted and which resources it would affect? If we could use a name that minimized the number of resources that were renamed then it could be used.

Making such a change may affect a large number of users due to the wide use of this resource module, so I'd like to get community input on such a change before going ahead with it.