views:

678

answers:

4

We have an Excel 2002/XP based application that interacts with SQL 2000/5 to process fairly complex actuarial calculations. The application performs its function well, but it's difficult to manage.

We're trying to create a "controller" application or service that can manage and monitor these various instances of Excel (start/stop/process commands etc) but it's a bit of an InterOp nightmare unfortunately.

Does anyone have a good (i.e. working) example of doing something like this in VB.Net or C#?

+1  A: 

You might want to take a look at this product: http://www.spreadsheetgear.com/products/spreadsheetgear.net.aspx

It's all managed code and direct .NET libraries. No InterOp headaches. I haven't used it myself, but I've heard very good things from people in the finance world.

We did evaluate this product. Unfortunately it can't quite cover our needs and the conversion effort would be massive.
Sean Gough
+3  A: 

Don't do it!

We tried for weeks to get something like that to work and it simply does not behave as advertised. Don't even start - give up immediately!

The only options that you really have is a heavy server-side MOSS based implementation - Excel (Web) services (they call it something like that). Windows based COM Excel interop is pretty much dead and will be replaced by MOSS.

The other option is to use SpreadsheetGear. It is actually a fantastic product

  1. It is lightlingly fast
  2. The engine is separate from the UI so you can use it to do Excel stuff server side (with no office installed)
  3. Fairly cheap
  4. Has an API similar to the existing Excel COM api so moving code across is relatively easy

It all depends on the formulas that you need in your spreadsheet. Have a look at the formula list for Spreadsheet Gear and if there is a match go for it.

Simon Munro
"Don't even think about it!" seems to be a common response. I think we're going to try and write a simple "start/stop/kill" type service but the consensus seems to be that actually interacting with multiple instances is a dangerous road to go down.
Sean Gough
+1  A: 

We have written a service that controls a single instance of Excel 2003. We never managed to get Excel instances to close cleanly, so we start one instance when the service is first accessed and use only that, serializing client requests.

Ian Horwill
+2  A: 

Interop works fine except that you always end up with references to Excel objects that aren't released, so Excel instances won't close. The following KB article explains why:

http://support.microsoft.com/default.aspx/kb/317109/EN-US/

You can avoid the problem if you have very carefully written code for a limited set of Interop scenarios. But in the general case it's very difficult to get it working reliably.

Joe