Trouble Programming from DotNet Against Multiple Excel Versions
 

My application works with Excel to put together spreadsheets for
reporting purposes. It runs just fine on my box, but when I put it on
another one, it bombs.

Here is the relevant code:

Public Function ImportSis(ByVal strSisFile As String) As Boolean
If m_Excel Is Nothing Then
m_Excel = New Excel.Application
End If
m_Excel.Visible = True
Dim oSis As Excel.Workbook
oSis = m_Excel.Workbooks.Open(strSisFile)

At that point, I get a NullReferenceException, saying that oSis hasn't
been instantiated. This method, though, returns a new reference so
instantiation should be irrelevant. For grins, I did a NEW right before
on the oSis, but got the same error.

This code runs just fine on my development box, running Excel 2003. It
also runs on another box that has Excel 2002. It bombs when on a box
running Excel 2000. I originally had used the reference for "Microsoft
Excel 11.0 Object Library" but when I suspected I had a versioning
problem I removed that reference, grabbed an "Excel09.olb" file off of
someone else's box running Office 2000, and made a reference to THAT
instead. That didn't solve my problem, though, and I just now took
another look at it and it somehow got back to the 11.0 version; weird.

Long story; anyone have any suggestions? How can I correctly reference
an Excel 2000 library instead, and do I need to worry about detecting the
version of Excel to load maybe a different version of the library at
runtime?

I appreciate any help.

--
Michael

Trouble Programming from DotNet Against Multiple Excel Versions
 

Develop on the lowest version of excel that will use the app.

--
Regards,
Tom Ogilvy

"Michael Kellogg" wrote in message
48.16...
My application works with Excel to put together spreadsheets for
reporting purposes. It runs just fine on my box, but when I put it on
another one, it bombs.

Here is the relevant code:

Public Function ImportSis(ByVal strSisFile As String) As Boolean
If m_Excel Is Nothing Then
m_Excel = New Excel.Application
End If
m_Excel.Visible = True
Dim oSis As Excel.Workbook
oSis = m_Excel.Workbooks.Open(strSisFile)

At that point, I get a NullReferenceException, saying that oSis hasn't
been instantiated. This method, though, returns a new reference so
instantiation should be irrelevant. For grins, I did a NEW right before
on the oSis, but got the same error.

This code runs just fine on my development box, running Excel 2003. It
also runs on another box that has Excel 2002. It bombs when on a box
running Excel 2000. I originally had used the reference for "Microsoft
Excel 11.0 Object Library" but when I suspected I had a versioning
problem I removed that reference, grabbed an "Excel09.olb" file off of
someone else's box running Office 2000, and made a reference to THAT
instead. That didn't solve my problem, though, and I just now took
another look at it and it somehow got back to the 11.0 version; weird.

Long story; anyone have any suggestions? How can I correctly reference
an Excel 2000 library instead, and do I need to worry about detecting the
version of Excel to load maybe a different version of the library at
runtime?

I appreciate any help.

--
Michael

Trouble Programming from DotNet Against Multiple Excel Versions
 

"Tom Ogilvy" wrote in message
...
Develop on the lowest version of excel that will use the app.

--
Regards,
Tom Ogilvy


I agree with Tom. Problem is that it seems as if you did what he suggested.
I can only recommend that you try agin but make sure you delete temporary
files and rebuild everything.

/Fredrik

Trouble Programming from DotNet Against Multiple Excel Versions
 

No he didn't. (from what I can see)
This code runs just fine on my development box, running Excel 2003.
I suspect he develops on his development box.

copying an object library that isn't installed isn't going to resolve the
problem I wouldn't think. I suspect the reference is immediately upgraded
(which seems like what he describes).

--
Regards,
Tom Ogilvy


"Fredrik Wahlgren" wrote in message
...

"Tom Ogilvy" wrote in message
...
Develop on the lowest version of excel that will use the app.

--
Regards,
Tom Ogilvy


I agree with Tom. Problem is that it seems as if you did what he
suggested.
I can only recommend that you try agin but make sure you delete temporary
files and rebuild everything.

/Fredrik

Trouble Programming from DotNet Against Multiple Excel Versions
 

"Tom Ogilvy" wrote in message
...
No he didn't. (from what I can see)
This code runs just fine on my development box, running Excel 2003.
I suspect he develops on his development box.

copying an object library that isn't installed isn't going to resolve the
problem I wouldn't think. I suspect the reference is immediately upgraded
(which seems like what he describes).

--
Regards,
Tom Ogilvy


Aha. Now I understand. Copying an olb file worked for me when I made an ATL
C++ project. But Michael is using a .NET language. I think he may need to
create a Primary Interop Assembly file. At least, that's what I think is
needed when you make a COM add-in. I think this question should be posted to
the public.office.developer.com.add_ins newsgroup.

Alternatively, if this isn't an add-in, Excel 2000 should be installed and
then make a reference to that type library.

/Fredrik

Trouble Programming from DotNet Against Multiple Excel Versions
 

In the old days, we'd say "Use late binding". I don't suppose dot-net
and managed code supports that option, does it?

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Peltier Technical Services
Tutorials and Custom Solutions
http://PeltierTech.com/
_______

Fredrik Wahlgren wrote:

"Tom Ogilvy" wrote in message
...

No he didn't. (from what I can see)

This code runs just fine on my development box, running Excel 2003.

I suspect he develops on his development box.

copying an object library that isn't installed isn't going to resolve the
problem I wouldn't think. I suspect the reference is immediately upgraded
(which seems like what he describes).

--
Regards,
Tom Ogilvy



Aha. Now I understand. Copying an olb file worked for me when I made an ATL
C++ project. But Michael is using a .NET language. I think he may need to
create a Primary Interop Assembly file. At least, that's what I think is
needed when you make a COM add-in. I think this question should be posted to
the public.office.developer.com.add_ins newsgroup.

Alternatively, if this isn't an add-in, Excel 2000 should be installed and
then make a reference to that type library.

/Fredrik

Trouble Programming from DotNet Against Multiple Excel Versions
 

"Tom Ogilvy" wrote:

Develop on the lowest version of excel that will use the app.


Excellent advice.

I got upgraded to 2003 several months ago because one of our projects
needed an app that worked with Word 2003; this because the files being sent
to us by our client were in some new Word XML format that no other version
could work with. So now here I sit, with versions almost no one else here
has. The question is, should I remove my copy of Office and have 2000 re-
installed? Or should I get everyone else upgraded at least to 2002, where
compatibility will be less of an issue. Personally I'd prefer the latter
for a number of reasons.

I appreciate the feedback.

--
Michael

Trouble Programming from DotNet Against Multiple Excel Versions
 

Jon Peltier wrote:

In the old days, we'd say "Use late binding". I don't suppose dot-net
and managed code supports that option, does it?

- Jon

Sure it does. That's an interesting idea. In fact, if I were expressly
trying to service under multiple versions of Excel, I might HAVE to do it
this way. Say my user base had like 4 different versions of Excel. Even
if my development box was running the "lowest common denominator," would
my code run on all 4 versions? Could I instantiate my m_Excel as an
"Object" and then cast it or something later (Can you do casting in
VB.Net? It seems like CType is a one-time-only thing)? How do you
create a reference out of nowhere at runtime (I'm thinking some system
method that takes a filename)?

I'm not a late binding fan, anyway, although that could just be me being
ignorant.

--
Michael

Trouble Programming from DotNet Against Multiple Excel Versions
 

I am sure Microsoft would prefer the latter if you can still get licenses.
I don't develop in Net, but I believe I read something about the InterOp
whatever not being available for older versions of excel (don't recall if it
was 2000 and earlier or 2002 or earlier). In any event, you have proved the
2002 will work, so upgrading sounds best.

--
Regards,
Tom Ogilvy



"Michael Kellogg" wrote in message
8.16...
"Tom Ogilvy" wrote:

Develop on the lowest version of excel that will use the app.


Excellent advice.

I got upgraded to 2003 several months ago because one of our projects
needed an app that worked with Word 2003; this because the files being
sent
to us by our client were in some new Word XML format that no other version
could work with. So now here I sit, with versions almost no one else here
has. The question is, should I remove my copy of Office and have 2000 re-
installed? Or should I get everyone else upgraded at least to 2002, where
compatibility will be less of an issue. Personally I'd prefer the latter
for a number of reasons.

I appreciate the feedback.

--
Michael