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
- but I could still find all of its values via
… 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.