Thank you for your response Caroline, but it does seem you haven't read everything else that has been posted in this thread.
I have no problem that your library being unable to open files if Excel can't. It is a fallacy your product works like Excel though; yes you followed the ECMA standard (not Microsoft), but your library is managed code and doesn't have the same internal logic/defaults that Excel sets. An example is that your library quite happily allow duplicate "PRINT_AREA" areas in a document, where Excel complains about them and requires them renamed before it will open.
Your library currently throws manageable exceptions if it is unable to open a file, in this case it throws an exception with the message "Root element is missing"; which can and is handled. It is the second exception, which occurs when the application or thread is terminated, that absolutely kills my application. The fact that I'm unable to handle the second exception means I have to treat any code that uses your library as unstable and not fit to be deployed into my production environment.
I'm also shocked to say the least with your dismissive reply, as your colleages have been hounding me to provide a file before you can offer any sort of help or investigation into this issue. Now that I've provided such a file all the previous posts are dismissed, and a simplisitic reply is given. I am fast approach the point where I need to make a recommendation to my management on what library we should purchase and implement into our systems. At the moment, and increasingly so with the last reply, I'm finding it extremely hard to make a case for Spire.Office.
Is there an alternative support route I should try for a better result?