>>Although I've never used it I'd just about gaurantee that Excel has to be installed. You might look here for a better solution:
>>
>>http://www.aspose.com/Products/Aspose.Cells/Default.aspx
>
>Presently, it turned out that I am now doing something like this:
>
>

>            oDataProvider.oDataSet.WriteXml(oApp.cHttpFat + lcFile, XmlWriteMode.IgnoreSchema)
>

>
>This creates an XML that Excel can read. However, it is somewhat irritating as this is not native Excel, so Excel will prompt for the XML dialog, shows another dialog with errors even if there are no error as everything says Complete in it.
>
>For now, I will keep that approach. If the client wants something native, as we don't have Excel on the server, I will have to consider using such a tool as you mentioned.

Michel,

Yes, Excel must be installed on the server to use Interop. The Office Interop dlls are wrappers for the COM+ servers. This is very dangerous on a production server because the Excel COM+ interface has some well-documented glitches that can leave instances hanging and cause all sorts of problems.

To be absolutely certain that an Excel COM+ instance is shut down requires a .NET Garbage Collector Flush. This is a huge performance hit on a server because _all_ .NET threads are put into a wait state while the GC completely flushes it's heaps.

The safer and better-performing alternative is to use the Office XML schemas to create the XML spreadsheet file natively in .NET. Unfortunately, this is not a simple task because the Excel schema is complex.

I haven't found anything like an Office XML schema tutorial on the web. It seems that the schemas are still new enough and the learning curve high enough that no one is willing to freely impart their knowledge just yet.

Sorry for the bad news.