I get this question every couple of months. Somebody has a process that requires an Excel file to be cracked open and read on the server.

Since we're talking about server-side manipulation, that rules out any techniques based on the Excel object-model itself. The OM requires the presence of Excel and the Excel application is not supported on a server. That means VSTO is not a consideration here since it depends on the Excel OM. You have three viable options. They are (in no particular order):

Excel Services (Requires SharePoint Server 2007; Excel 2007 to publish) Excel Services wraps published workbooks in a SOAP wrapper. This is very useful for invoking user-defined functions, or retrieving named items or named ranges and charts. It is also going to allow you to render some or all of a workbook in a SharePoint site without doing extra work.

SQL Server Integration Services (Requires SQL Server 2005 or later) SQL Server can import the data that resides in an Excel workbook. This gets you out of Excel data processing and into RDBMS processing. This works well with scheduled jobs, but the SSIS packages can be run on-demand programmatically. SSIS can use the new ACE engine to access Office 2007 file formats. It can also be used on earlier formats - a good way to get around JET. The ACE engine is available here: http://www.microsoft.com/downloads/details.aspx?FamilyID=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en

.NET Packaging API (Requires .NET 3.0 or later; Office 2007-formatted documents) In the .NET Framework 3.0, the System.IO.Packaging namespace was added. This provides the ability to manipulate files saved in Office Open XML format. You don't need Excel on the server, you don't need additional processing engines like SharePoint or SQL Server to do the dirty work. The downside is that the API does not have application-specific intelligence. It works directly with the raw XML stored inside of the file. That means it isn't going to know what a range is or how to execute a UDF. You're going to get the XML and you'll need to XPath and XSLT your way through it. There is a project on CodePlex called ExcelPackage which does wrap the Packaging API with some Excel-specific classes. It is worth checking out.

ExcelPackage: http://www.codeplex.com/ExcelPackage
Office Open XML documentation: http://openxmldeveloper.org/