Referencing older version of Excel

Hi all,

I am developing a WinForms app that will be accessing Excel. The problem is that i have a Excel 2003, and the client has Excel 2002, and I dont have a reference to any older versions of Excel. The only COM components i have for Excel are:
Microsoft Excel 11.0 Object Library
Microsoft Excel 5.0 Object Library

If i reference 11.0, then it will cause errors when the client installs and runs the app. What I would like to do is get Microsoft Excel 9.0 Object Library (Excel 2000) without actually installing Office 2000.

I know i must be overlooking something, but any ideas on how I can download this COM component to use as a reference?

Thanks in advance for any help.

~Scott~

Often times, situations like these require late binding to ensure that whatever version of excel is installed on the client, VB will be able to create that object.

Late binding has plenty of downsides, but sometimes it is needed when your app needs to work with office, but you can't guarantee the version of office that it will reference.

here is a little info on the late versus early, in relation to automating office
http://word.mvps.org/FAQs/InterDev/E...ateBinding.htm

I ran into this too...

Download the redistributable Office XP Primary Interop Assemblies here:

http://www.microsoft.com/downloads/d...displaylang=en

Hi Matt,

Excellent idea. I didn't even think to do that. Thank you very much.

~Scott~

Quote:

---

Originally Posted by BobTheBuilder.

I ran into this too...

Download the redistributable Office XP Primary Interop Assemblies here:

http://www.microsoft.com/downloads/d...displaylang=en

---

Bob, I don't think that will solve the issue in this case.

Reason being he needs to DEVELOP the app with office references... and just those PIAs alone (without office installed) will not allow that. They are to redistribute to an end user who has office installed, to work between your app and office.

Scott-
Just be careful, using late binding in .NET requires option strict be turned off. I recommend you put your code that uses late binding in a seperate class/module, and turn option strict off at the top of the code module, while leaving it on in all other places of your app.

Issues you will run into with the office automation can really vary depending on what you are using the office reference for, but if its pretty basic, then usually it will work with most versions. For example, lets say you write code to do something that is new to office 2003, obviously when you try to late bind to the new class/object on a user running office 2000, it will fail.

It is highly recommended you at least set up a test machine with the versions of office you plan on using this app with, and test it out. I know this isnt always possible to do, depending on what your testing environment may be like, but its a good idea if possible.

Matt-

Can't you just reference the older DLL that is in that PIA and redistribute it with the app?

Honestly, I don't know. I guess it is worth a shot, but my thinking is that lets say you did reference the DLL that is in the PIA on your development machine.

That PIA is for office XP and is just a link between office XP itself, and your program.

So the PIA dll will then go looking for office files that aren't there on your development machine, because you run office 2003, and its looking for office XP files and will probably fail. Because when you reference the PIA's its creating an early bind, requiring specific binds with the objects.

Like I said, it may be worth a shot, but I don't think it would work

Quote:

---

Originally Posted by kleinma

Honestly, I don't know. I guess it is worth a shot, but my thinking is that lets say you did reference the DLL that is in the PIA on your development machine.

That PIA is for office XP and is just a link between office XP itself, and your program.

So the PIA dll will then go looking for office files that aren't there on your development machine, because you run office 2003, and its looking for office XP files and will probably fail. Because when you reference the PIA's its creating an early bind, requiring specific binds with the objects.

Like I said, it may be worth a shot, but I don't think it would work

---

Well I recently wrote an app for the place I work and like I said I ran into this problem. They run Office XP on their machines and I wrote the app using my machine which has Office 2003 installed.

So after I finished the app and installed it I tested it on a different machine and CRAP it threw an exception. To make a long story short I read up on a bunch of MSDN articles (and I possibly did this wrong) but I installed the PIAs onto my machine, made a reference straight to the DLL file that I wanted, and my app works! My app also works on machines Office 2003 as well.

Perhaps I misinterpreted what the PIAs we for but I thought they were for use if you wanted to create an app for a previous version of Office...well either way it worked for me! Sorry for high-jacking the thread! :eek:

it may be that the PIA's exhibit a forward compatibility so if you use old office PIA's, they will run on that version of office and up... I am not sure if there are any dangers with that, like an XP PIA running into something in office 2003 that is just different from the way it was in office XP. Like I advised to Scott above, regardless of what route is taken to solve the problem, extensive testing should be done using whatever versions of office you can anticipate being used.

You didn't hijack the thread, there is nothing wrong with anything you posted.

Thanks for all the replies, Bob and Matt. You both bring interesting points to the table.

Matt, i have tried using option strict on, but ran into too many problems that i didnt have time to figure out. One day, i will be at a level where i can use option strict on. So, that is not an issue as of now.

All I will be doing is accessing data in the cells of a report in Excel, so nothing fancy will be happening. I think all versions of Excel will be able to handle that.

Bob, i actually did try your idea, but, for some reason, i couldn't get the Excel 10.0 Object Library to install. Decided i would just go the route that Matt has suggested.

Thanks to you both. And please, if anyone wants to add to this thread with other ideas, i am sure a lot of people run into problems such as these and would like as many options as possible.

~Scott~