Version Proofing Excel COM/.NET Wrapper

[news.microsoft.com]

Not sure the best group to post to, so sorry for the cross post :(.

There are several posts out there of how to automate excel from .net, i.e in
the sample below, they are using Excel 9.0... However, on my machine, I have
12.0... no big deal.. I see both in the post below, and on my machine, there
is also a 'Microsoft Excel 5.0 Type Library'. Is it best to use this
reference to be able to target an arbitrary version? I'd assume that there
are obvious limitations in using an older version, but I'd assume that the
basics of reading/writing cells, navigating, creating a sheet, etc, would be
supported?

Is my thinking correct, or is there another 'best practice' to version proof
a utility that will be shared with others that may/may not have the same
version I have?

http://www.c-sharpcorner.com/UploadF...iewin.NET.aspx

"The first step is to create a reference in your project to Excel 9.0
Objects Library. This is done by right mouse clicking on the References
folder in the Solution Explorer and choosing Add Reference. This brings up
the Tab Dialog below. Choose the COM Tab and pick Microsoft Excel 9.0
Objects Library."

[Kalpesh]

Note: I have not come across such a scenario.

However IMO, using latest COM library for Excel 12.0 might save the file
as xlsx or according to new format. Older ones such as 5.0 might create
xls file or old format.

As long as basics are concerned for reading to file/writing to file - it
should work as expected. Higher versions might take care of lower
version files (for backward compatibility)

So, if all users do not have excel 12.0, I would suggest using VB6 way
of instantiating excel (e.g. CreateObject("Excel.Application"). This
used to invoke appropriate Excel automation instance irrespective of
which ver. of Excel is installed. This method is a late-bound approach
so, it might not have IDE support & method calls might be little slow.

MSDN might have a better solution or VBA/VSTO MVPs can suggest better
ways & also correct me, if I am wrong in my understanding.
news.microsoft.com wrote:

Not sure the best group to post to, so sorry for the cross post :(.

There are several posts out there of how to automate excel from .net, i.e in
the sample below, they are using Excel 9.0... However, on my machine, I have
12.0... no big deal.. I see both in the post below, and on my machine, there
is also a 'Microsoft Excel 5.0 Type Library'. Is it best to use this
reference to be able to target an arbitrary version? I'd assume that there
are obvious limitations in using an older version, but I'd assume that the
basics of reading/writing cells, navigating, creating a sheet, etc, would be
supported?

Is my thinking correct, or is there another 'best practice' to version proof
a utility that will be shared with others that may/may not have the same
version I have?

http://www.c-sharpcorner.com/UploadF...iewin.NET.aspx

"The first step is to create a reference in your project to Excel 9.0
Objects Library. This is done by right mouse clicking on the References
folder in the Solution Explorer and choosing Add Reference. This brings up
the Tab Dialog below. Choose the COM Tab and pick Microsoft Excel 9.0
Objects Library."

[=?Utf-8?B?dmFwb3I=?=]

I think this approach is acceptable. Personally, I prefer targetting a
specific version of Excel and 'certifying' my application to run against that
version. It's much simpler for trouble-shooting and all those other version
compatibility issues that drive developers wild. However, this is strictly
according to taste and is certainly not the only way to do it.

"Kalpesh" wrote:

>
Note: I have not come across such a scenario.

However IMO, using latest COM library for Excel 12.0 might save the file
as xlsx or according to new format. Older ones such as 5.0 might create
xls file or old format.

As long as basics are concerned for reading to file/writing to file - it
should work as expected. Higher versions might take care of lower
version files (for backward compatibility)

So, if all users do not have excel 12.0, I would suggest using VB6 way
of instantiating excel (e.g. CreateObject("Excel.Application"). This
used to invoke appropriate Excel automation instance irrespective of
which ver. of Excel is installed. This method is a late-bound approach
so, it might not have IDE support & method calls might be little slow.

MSDN might have a better solution or VBA/VSTO MVPs can suggest better
ways & also correct me, if I am wrong in my understanding.
news.microsoft.com wrote:

Not sure the best group to post to, so sorry for the cross post :(.

There are several posts out there of how to automate excel from .net, i.e in
the sample below, they are using Excel 9.0... However, on my machine, I have
12.0... no big deal.. I see both in the post below, and on my machine, there
is also a 'Microsoft Excel 5.0 Type Library'. Is it best to use this
reference to be able to target an arbitrary version? I'd assume that there
are obvious limitations in using an older version, but I'd assume that the
basics of reading/writing cells, navigating, creating a sheet, etc, would be
supported?

Is my thinking correct, or is there another 'best practice' to version proof
a utility that will be shared with others that may/may not have the same
version I have?

http://www.c-sharpcorner.com/UploadF...iewin.NET.aspx

"The first step is to create a reference in your project to Excel 9.0
Objects Library. This is done by right mouse clicking on the References
folder in the Solution Explorer and choosing Add Reference. This brings up
the Tab Dialog below. Choose the COM Tab and pick Microsoft Excel 9.0
Objects Library."