Trouble Programming from DotNet Against Multiple Excel Versions

[Michael Kellogg]

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

[Tom Ogilvy]

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

--
Regards,
Tom Ogilvy

"Michael Kellogg" <[email protected]> wrote in message
news:[email protected]...
> 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
>

[Fredrik Wahlgren]

"Tom Ogilvy" <[email protected]> wrote in message
news:%[email protected]...
> 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

[Tom Ogilvy]

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" <[email protected]> wrote in message
news:[email protected]...
>
> "Tom Ogilvy" <[email protected]> wrote in message
> news:%[email protected]...
> > 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
>
>

[Fredrik Wahlgren]

"Tom Ogilvy" <[email protected]> wrote in message
news:%[email protected]...
> 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

[Jon Peltier]

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" <[email protected]> wrote in message
> news:%[email protected]...
>
>>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
>
>

[Michael Kellogg]

"Tom Ogilvy" <[email protected]> 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

[Michael Kellogg]

Jon Peltier <[email protected]> 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

[Tom Ogilvy]

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" <[email protected]> wrote in message
news:[email protected]...
> "Tom Ogilvy" <[email protected]> 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