pontifikas,
There are a number of options you have here, none of them too appealing
(IMO).
The first would be to set references to each version of office in your
app. Then, you have to determine which version is installed, and make the
call to the appropriate version from your code. This will require a good
number of switch statements, and is very unwieldy. Of course, you could
create wrappers which expose the APIs that you wish, but given the size of
the Excel API, it's impractical.
I'm not sure about this one, but you could try and add a reference to
the lowest version of Excel you will support, and only make calls to the
functions on that version you know are supported. The new implementations
should support the old interfaces.
I think the best solution would be to use VB for all of your calls to
Excel. Basically, you can create an instance of Excel and assign it to a
reference of type object. Once you do that, you can make late bound calls
to the object. This would allow you to assign any instance to the
reference, and have the calls succeed, as long as all the calls have the
same naming/calling convention across versions.
Of course, the last option has a perf hit, but if you have to maintain
reams of Excel code across versions, then it's the best way to go. You can
always place all of the other Excel calls in types in another assembly, and
then reference it from C#. You could do this in C#, but it would require a
number of reflection calls which is also unwieldy.
Hope this helps.
