Improved backward compatibility in PowerCLI 4.1.1

The new PowerCLI 4.1.1 has improved compatibility with scripts written for PowerCLI 4.0.1 and earlier.

PowerCLI 4.1 moved cmdlet output types to new namespaces. This introduced incompatibility with scripts which depend on output types’ full namespace path. To negate the impact of the change and to enable a transition period in which scripts can use full references to both old and new namespaces, PowerCLI 4.1.1 includes additional set of types which reside in the old namespaces (“the old types”) and are implemented by types in the new namespaces.

In practice, this means that code like:
function BackupVM ([VMware.VimAutomation.Types.VirtualMachine] $myVM) { … }
function BackupVM ([VMware.VimAutomation.Client20.VirtualMachineImpl] $myVM) { … }
works with PowerCLI 4.1.1 even though the correct (new) types are:
function BackupVM ([VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine] $myVM) { … }
function BackupVM ([VMware.VimAutomation.ViCore.Impl.V1.Inventory.VirtualMachineImpl] $myVM) { … }

IMPORTANT: The described compatibility support is temporary. We plan to remove the old types in the release following 4.1.1. This means that no new scripts should be written based on the old types and legacy scripts should be updated to remove dependencies on the old types.

As always, it is advisable to avoid full namespace references where possible, and to reference types in the *.Types assemblies instead of their *.Impl counterparts.

Andrey Anastasov,
PowerCLI architect


3 comments have been added so far

  1. Hi Andrey, thanks for the informative post.
    I understand that we should use the Types assemblies instead of the Impl assemblies.
    But that will not avoid future incompatibilities as far as I can see.
    The current Types assembly contains for example VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine.
    But this seems to indicate that there will be a V2, V3… in the future.
    Again the script will have to be updated.
    Isn’t it better to have a static VMware.VimAutomation.Types.VirtualMachine that we can use in scripts all the time ?

  2. Hi Luc,
    We’d like to keep things as close to the example you’re giving as possible. The V1/V2/… part of the name does not indicate intent to make frequent changes. The namespace is meant to change rarely – its purpose is to accommodate breaking changes only when they are inevitable and to do so in a non-disruptive way. We plan for transition period in which both versions are supported.
    As you suggest, it is possible to keep a single type and rely on PowerShell’s type adaptation system to do the job. The downside of this approach is that it leaves us no options for providing backward compatibility to .Net applications which reference PowerCLI types.

  3. “…even though the correct (new) types are…”
    I am sorry. The correct types were the old ones. The new ones reflect a poor understanding of public namespaces.

Leave a Reply

Your email address will not be published. Required fields are marked *