[Bug] PowerShell Import-CliXml incorrectly creates Hashtables with duplicate keys

Import-CliXml is a rather convenient way to import (configuration) data from serialized XML files which then can be easily processed as hashtables. But unfortunately, there seem to be some subtle bugs in the implementation of the Cmdlet (remember the implicit type conversion I wrote about before). This time it hit me when I was debugging a strange behaviour when using Enter-Infoblox which is part of our biz.dfch.PS.Ipam.Infoblox.Api PowerShell module. Strangely this had been working for months and all of a sudden it refused to perform a login.

Unfortunately, I had not been using Pester when I first created the module so I had to manually debug the problem and could not rely on unit tests to isolate the problem. After some investigation I saw that the serialised hashtable that I imported from the XML configuration file contained duplicate key names – something you would think is impossible for a hashtable … However, It was actually true and fully reproducible as you can see here:

PS > $ht = Import-Clixml .\HashtableDuplicateKey.xml
PS > $ht.GetType()

IsPublic IsSerial Name      BaseType
-------- -------- ----      --------
True     True     Hashtable System.Object
PS > $ht

Name          Value
----          -----
DuplicateKey  some other arbitrary value
DuplicateKey  arbitrary value

But even stranger than a hashtable with duplicate keys was the fact that it still did not behave consistently:

  • I could still Clone() the hashtable (effectively getting another broken hashtable)
  • I could not access either of the duplicate keys with ContainsKey() though it was shown to me in the Keys collection.
  • but I could still find all of its values via ContainsValue()

… very weird! After some investigation it turned out that someone modified the XML file on disk manually and accidently duplicated one of the keys, which then led to this incident. I created some Pester tests to demonstrate the behaviour (you can simply clone the repo and run Invoke-Pester in that directory).

In addition I opened an issue at Microsoft Connect. Maybe this once gets fixed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: