Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#2
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#3
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#4
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#5
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#6
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#7
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#8
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
#9
Posted to microsoft.public.excel.programming
|
|||
|
|||
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 |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
How to you open multiple versions of Excel | Excel Discussion (Misc queries) | |||
Multiple Excel versions. | Excel Discussion (Misc queries) | |||
VB6 COM Add-In for multiple Excel and Word versions | Excel Programming | |||
VB6 COM Add-In for multiple Excel and Word versions | Excel Programming | |||
updating Excel from DotNet | Excel Programming |