I've seen this done
I worked on an MFC application that used Excel to generate tabular reports. The spreadsheet didn't do any calculating. Basically the application created a new spreadsheet, created the headings, and then filled in the tabular data.
I managed to get Excel working with ASP.Net on a different project. The customer wanted this so they could enter Excel spreadsheets into their database, and get data from the database into Excel workbooks via. a web app.
It's an odd scenario. You literally install Excel on the server, give the ASPNET user permission to access Excel via. DCOM, and install the Excel PIAs (Primary Interop Assemblies). I wrote my Excel interop. code in VB.Net. It's just easier that way. In it I invoked Excel and loaded a spreadsheet that had been previously uploaded to the server. I also turned the application's visibility off (no reason to have it draw the UI). The weird part is you don't interact with Excel the way you would with a normal API. You call functions that almost literally carry out actions a user would take. So it takes a different approach to get it to work.
The challenges with running Excel on the server are scalability (there really isn't any), and getting Excel to shut down when you're done with it. Unfortunately the Excel PIAs do not gracefully detach from the COM objects that actually do the work, the way VBScript did in old ASP.
The only time you'd want to run Excel, or any Office application, on the server via. ASP.Net is if it were rarely invoked and by only 1 or 2 people at a time. Microsoft does not recommend running Office with ASP.Net, since it wasn't designed to work in a multithreaded, multi-user environment, but that hasn't stopped people (like me) from using it on the web. From what I've read, Office 2007 is going to change this. They've introduced new features into the .Net Office API so that Office documents can be accessed (to put data into them or get data out) without actually running the Office applications.
At first I was puzzled why the customer wanted to enter data into spreadsheets, since we had a data entry facility in the web application. I came to admire their approach, because they were literally entering hundreds of data points in the spreadsheet. Excel is well suited to the task. I had the thought that if I were to write an application to take in all that data, and do the calculations that the spreadsheet did, it would've taken me a long time to do, and cost them more money. Using Excel was the right move. Upon reflection, I think a smarter move would've been for me to use .Net/Excel interop. to create some custom programming for Excel to execute to put data in and get data out of their database, as opposed to using a web app. to do it. I suspect it would've been less complicated.
