You don't need to build up much of anything in XML. I've created XML files that point to an XSL files which contains a transform to tables in HTML; when opened in Excel it draws up the tables accordingly. Same deal but a little more straightforward is to transform the XML to HTML or CSV directly in the creation code. The upshot is, you roughly outline how your XML is going to look and then either alther the XSL to suit or point to one of several XSL files, both of which are a lot easier than redoing source code for the original application.
Do you suggest to replace the following workflow...
1. Acquire data
2. Build table in memory
3. Try to acquire InterOp application (may fail)
4. Transfer table (as obj[][] or obj[,])
...with something like this?
1. Acquire data
2. Determine temporary or final file name
3. Build XML
4. Transform XML
5. Save file
6. Try to acquire InterOp application (may fail)
7. Open file in application
then it would appear that the steps 2), 4) and 5) are somewhat additional.
If you want late binding just use VB.NET
Care to expand on that statement? (Surely you don't mean that one can omit Void parameters in VB.)
Cheers, Thorsten