
excellibrary - issue #90
An item with the same key has already been added ( for reading excel files with macros inside )
What steps will reproduce the problem? 1. Reading a 2003 excel file with macros.
What is the expected output? What do you see instead? Expect the contents to be read, but instead gets an exception. "An item with the same key has already been added."
What version of the product are you using? On what operating system? .Net ver 2 Framework.
Please provide any additional information below.
Comment #1
Posted on Jun 8, 2011 by Grumpy CatThis issue occurs in the "Name" getter of the "DirectoryEntry". The condition for checking the "NameDataSize" returns an empty string if "NameBuffer" contains only one char. So the "Members" Property throw an Exception while adding a second DirectoryEntry with empty Name.
Comment #2
Posted on Mar 28, 2014 by Swift Kangarooand what is the solution?
Comment #3
Posted on Aug 20, 2014 by Happy PandaFor what it's worth...
I recently hit this same problem. I imagine there are multiple reasons why this could happen. As the previous poster alluded, the error stems from the initialization of a dictionary of component parts, the key to which is the part's name. The exception is thrown when more than one part has the same name (within the part's parent).
In my case, this situation was caused by the presence of VB forms in my file. For reasons I never spent the time to completely understand, some of the component parts of a form did not have names (the value was an empty string), so when the second one for a given form was encountered, the exception was thrown when an attempt was made to put in the dictionary. (By the way, I was able to get this far only be downloading and stepping through the source code).
I was lucky in that I could request that the files be sent to me as .xlsm instead of .xls, and as a result, I was able to use a different utility to parse the file and problem solved (either because the new version of Excel doesn't store its data this way or because the utility I am using is more robust. Or both.)
Anyway, my fallback solution would have been to hack the source code to ensure that every component part had a name to use as its key in the dictionary (GUID). This was working for my particular problem, but I never got around to investigating what the potential fallout would have been from doing such a thing.
Status: New
Labels:
Type-Defect
Priority-Medium