An item with the same key has already been added ( for reading excel files with macros inside )

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by cmy...@gmail.com on 19 May 2011 at 4:59

[GoogleCodeExporter]

This 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.

Original comment by sebge...@gmail.com on 8 Jun 2011 at 8:33

[GoogleCodeExporter]

and what is the solution?

Original comment by jazz.hek...@gmail.com on 28 Mar 2014 at 3:48

[GoogleCodeExporter]

For 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.

Original comment by rickus...@gmail.com on 20 Aug 2014 at 9:18