>I have a basic question about reading, creating, and writing to MS Excel spreadsheets.
>
>If I know that the computer upon which I am installing an application has Excel installed on it, does Excel expose everything I need through its DLLs to open a spreadsheet and pull data out of it into a DataSet (not necessarily in a single method call) and to create an Excel spreadsheet, populate it, save it, etc.?
>
>Right now, we are using Crystal Reports to create an Excel spreadsheet. Is that necessary from .NET or is there a more direct route from from DataSet to .xls file?
>
>Can someone recommend a good API/SDK for MS Excel objects?
>
>Does the API/SDK vary much by version of MS Excel or are the exposed methods pretty consistent?
>
>How can I check, in code, for the presense of a needed DLL that I am not distributing? I don't think I can distribute MS Excel DLLs and I don't want to buy a license.
>
>Thanks.

David,

In addition to Cetin's response, there are issues with the Excel COM object that require additional code to make certain that the Excel application is shut down. Google "Excel application quit" to find solutions. Most of them involve flushing the .NET garbage collector which puts all .NET applications in a wait state until it is finished.

Microsoft states quite clearly that Excel COM is not designed for a server environment. Most of the COM calls are not thread-safe, and the COM server has an nack for freezing the entire server. If you plan to use it in a Web App, Web Service, or Windows Service, you are probably better off doing the alternative -

Microsoft provides an XML schema (xsd) file that describes the format of a native XML version of an Excel 2003 spreadsheet. Look for "office schema download" in the MS knowledgebase.