UPDATE 10-JAN-11: To deal with the issues identified below, I published a beta version of the VMware vSphere PowerPack with PowerCLI 4.1 or later support. You can read more about the beta and how to install it here.
Luc Dekens suggested that I share my concerns about upgrading to PowerCLI 4.1 U1 here so that the rest of the community could be aware of some of the details behind the issues between upgrading from PowerCLI 4.0 U1 to version 4.1 or 4.1 U1. Ask and ye shall receive. 
Back in July 2010 I shared my concerns about upgrading to version 4.1 of the PowerCLI due to a number of breaking changes introduced in that release. These changes were far reaching and have caused us challenges as we try to support the VMware community with our VMware PowerPack for PowerGUI®. A little while later, Scott Herold sat down with members of the PowerCLI team and they agreed to put in temporary support for the old object model as part of their 4.1 U1 release, so going forward this seemed like it would give us a smooth upgrade path for our customers. PowerCLI 4.1 U1 was released earlier this month, and it was supposed to address these issues while also including great new enhancements for the community. Unfortunately we were not aware of the release schedule for the PowerCLI, nor were we provided early release versions to work with, so while we were working on our PowerGUI Pro and PowerGUI 2.3 releases which included (among many other things) the VMware PowerPack for the first time, we had no choice but to include a firm requirement in the installer for PowerCLI 4.0 U1. This is why the VMware PowerPack will not install with PowerGUI Pro or PowerGUI 2.3 if you are using any version of the PowerCLI other than 4.0 U1. As a result, the inclusion of the VMware PowerPack in PowerGUI has met mixed reviews because many community members expected it to work with PowerCLI 4.1.1 out of the box, however we had no knowledge of that release during our own release cycle so we simply could not build-in support for that release.
Now that PowerGUI Pro and PowerGUI 2.3 are released as well as VMware’s PowerCLI 4.1 U1 though, which is supposed to come with complete support for the old type names, I suspected that I would be able to manually upgrade my PowerCLI to the latest version and that my PowerPack would continue to function the way it did before, possibly having a few minor issues to deal with. That suspicion has proved incorrect because of a number of problems. Based on my initial testing, here are the issues that I see in PowerCLI 4.1 U1:
- PowerCLI 4.1 U1 still returns the same type hierarchies that were returned in PowerCLI 4.1, which are not compatible with the VMware PowerPack which is based on the 4.0 U1 types. As indicated on the blog post titled “PowerCLI 4.1: A fork in the road”, these incompatibilities affect many community-driven content that is based on the PowerCLI, including the VMware PowerPack, the VMware Community PowerPack, books, blog posts, shared scripts on PoshCode, the VMware VI Toolkit Extensions module, etc. I have tested multiple commands (Get-VMHost, Get-VM, Get-Cluster, Get-Datacenter) against multiple labs using PowerCLI 4.1 U1 and none of them show the old type names, so backward compatibility is still broken as far as I can tell.
- When you invoke a PowerCLI cmdlet like Get-VM, if you show all of the properties for those VMs you will now see warnings about properties that are to be deprecated in a future release. The properties still work today, but the warning indicates they are obsolete and therefore they are not guaranteed to work tomorrow. The trouble is you see these warnings even if you are not directly using those properties. For example, if you invoke Get-VM and pipe that to Format-List * to see all properties, you’ll see warnings in the output before you see the results. In this case the warnings are benign (unless there are other warnings mixed in that should get your attention), however it shows a disturbing trend that VMware has taken to changing PowerCLI object data such that scripts that work today are not guaranteed to work tomorrow unless they are updated when the existing properties are deprecated, causing multiple rifts between users are on the current release and those who don’t upgrade right away. It means you will see multiple ways to do things in scripts over time that have different properties, and when you view those scripts you may or may not be aware of which is current so this is bound to cause some user confusion. This also makes it difficult for anyone to consider upgrading if you use anything with scripts that are dependent on the PowerCLI (PowerPacks for example), because there is no guarantee with this approach that those will not break when you switch from one version to the next unless you are sure they have upgraded to support new releases as well where object properties may deprecate over time. Blog content that normally could be published and left as is for a very long time may become out of date more quickly. Books will have a much more limited lifetime if they don’t use the right properties. And so on.
Breaking changes in any programming language are considered something to completely avoid unless those changes are absolutely necessary. On those rare few occasions when they are necessary, there are mechanisms in place that allow you to reduce the impact of those breaking changes (side-by-side versions for example). PowerShell has a rich Extended Type System that allows for type extensions so that you can evolve objects over time, using alias properties, script properties, code methods, etc. to allow you to continue supporting older versions while you upgrade your technology to new versions. All of these together should give cmdlet authors enough flexibility that they don’t need to introduce breaking changes haphazardly like this. Unfortunately I don’t feel that VMware gets this yet, but I continue to try to evangelize this and work with them so that this gets easier going forward.
If you have any questions about any of this, please don’t hesitate to ask.
Thanks,
Kirk out.
Poshoholic 