The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Excel COM reference in C# project

Hi All,

I am about to begin a project using that will tinker with spreadsheets from C# with the Excel COM Object library references.

Has anyone out there any experience with using this when the target environment has different versions of Office?

Is it best to just go for lowest common denominator?

Anything worth watching out for?

All thoughts & comments welcome.

Thank you,
Don Vince Send private email
Thursday, August 11, 2005
I would use VB.NET; the fact that you can do Option Strict Off saves a lot of casting; and makes the code much more readable.

Thursday, August 11, 2005
Hi Don,

You may want to check out Microsoft .NET Development for Microsoft Office by Andrew Whitechapel which I've started going through and found pretty reasonable.

Microsoft also has a sample chapter on MSDN.

Good Luck
Marcus from Melbourne
Thursday, August 11, 2005
I've had to give up on a .NET project that was using Excel to generate reports.

There are major problems with the Excel 2000 Object model, such that it fails unpredictably with automation from .NET (neither VB nor C#).

I've lost the bug report, but if you do some searching for Excel errors with .NET you'll find a number of problematic ones.
Roman (wishes things would just work sometimes) Send private email
Friday, August 12, 2005
If you can restrict your audience to Office 2003, my understanding is that Visual Studio Tools For Office have gotten quite good; I haven't tried the latest version.

If you need it to work cross-version of excel, you should use late binding.

In C#, this means lots of calls to obj.gettype().invoke(obj, params)
In VB.NET, I think you can use VB style obj.method, and the framework will convert it into invoke for you.
So use VB.NET if you want to use the .NET framework.

If you use regular COM interop, you may get strangeness because of how they're autogenerated.
If you use the Primary Interop Assemblies from Microsoft, you'll have to figure out how to match the PIA to the version of Excel--they mostly work if you have a version mismatch, but you'll have strange bugs.

Even more fun comes w/automation if the user has multiple versions of Excel installed, but adding .NET doesn't really change those problems much.
mb Send private email
Thursday, August 18, 2005
If you have the option to pay for a third party tool, I have mostly good things to say about the Aspose products (  They don't use automation, they generate the file directly from the object model - but I have only used the Word and PDF libs, never the Excel one.  You might give the trial a go though ..
Ross Send private email
Sunday, August 21, 2005
You also generally need to do something like this in order to avoid orphaned EXCEL.exe's floating around in taskmgr

Excel.Application excel = null;
Excel.Workbook wbk = null;

... // do some work

wbk = null;
if (excel != null) {
oExcel = null;
Tuesday, August 23, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz