PIAs: yes, that was basically a red herring, I'm afraid. For what you're trying to accomplish, it is quite possible that referencing the Excel 2002 PIAs can make things more complicated for you. Everything should be fine, so long as all the computers involved also have the Excel 2002 PIAs installed... but using a local IA can be easier.

A local interop assembly or (local IA) is what occurs when you reference Excel without there being any PIAs on the machine that is being used to run Visual Studio. In this case, the local IA will be placed within your project folder, and when you copy it into the destination machine, the local IA that you copied in will be your IA. It is not strong-named, so it is not a "Primary" IA, but it is a fully functional interop assembly, nonetheless.

The main reason that it is preferable to use Microsoft's provided Primary Interop Assemblies (PIAs) is so that various add-ins and programs can intercommunicate. If every add-in uses its own local IA for its reference to Excel then you cannot pass Excel Application objects (or any other Excel objects) between programs or add-ins.

However, I find that this need is extremely rare, in practice. You would only need it if your Excel add-in is communicating with another add-in and you are passing Excel object model references to one another. This is a very sophisticated approach and is not seen much. Even in this case, one could still pass string names, such as the string name for a workbook, worksheet, or the full path address to a range.

In short: don't be too worried about the PIA situation -- if you get it working using a local IA, then you are fine for what you're trying to do.

But if you now have the Excel 2002 PIAs installed on all the machines in question, then you should already be good to go. You might want to manually inspect the GAC on each of the machines that are not working to be 100% certain that the Excel 2002 PIAs are in fact there.

If this is fine, then what I do in situations like this is start with an extremely small test project that has minimal functionality, see if that works, and then keep adding aspects one at a time, until you hit a problem. For example, in this case, I would:

(1) Create a brand new project from scratch.

(2) Do NOT add any references to Excel -- not yet.

(3) Do add a reference to Extensiblity and implement IDTExtensiblity so that your class loads when Excel opens. Since you are not referencing Excel, you can't actually call it, not using early binding anyway. Have all 5 of the implemented IDTExtensibility interface methods be empty, except the startup method which can have a message box that reports "Startup sucessful!" or the like, so that you know that it is loading. You can put another MessageBox within the shutdown method as well.

(4) Test this project on the development machine: does it run?

(5) Register on one of the bad test machines and try running there. Does it work? If it fails here we know that it's not a PIA issue or anything else... although I suspect/hope that this all works fine.

(6) Add a reference to Excel. At startup, cast the 'object Application' reference that comes in via a parameter to an Excel.Application reference and report the .Version property via a message box.

(7) Test this new version on the development machine.

(8) Register and test on one of the bad machines. Does it run? If it fails here, then you definitely have a PIA or similar referencing issue going on. If it passes this test, however, then it is something else...

Basically, you just keep going, piece by piece, until you find the thing that goes wrong. At some point you will hit it...

I know that this is time-consuming, but I think that this is the only rational way to tackle a complex problem like this. This is the way I handle this kind of thing, anyway.

Good luck with it, and let us know how it goes... Let us know if you get stuck anywhere, and hopefully we can help.

Mike

Hi Mike,

I have read this post and your other notes on the issue. I have a similar problem:

My development machine has Office 2003 installed and my application (VB.NET 2005) references Excel 2003 PIAs.
the client machines all have Office XP installed, and there is o way for them to upgrade, yet.
What do you suggest, in this case, without having to maintain 2 separate instances of Office in our lab.

A quick response would be much appreciated. You have helped me in teh past and i am sure you will get me out of this one also.....!

__________________"With the appearance of the AddressOf operator, an entire industry has developed among authors illustrating how to do previously impossible tasks using Visual Basic. Another industry is rapidly developing among consultants helping users who have gotten into trouble attempting these tasks." -Dan Appleman

Ok, yes, start a new thread to ask your own question -- you can always post a link to the other related thread if you need.

To answer your question, normally you would want the Office Version you are targeting (Excel 2002 in this case) and Visual Studio on the same development machine so that you can develop and test properly.

If that can't be done, then I think you *should* be able to install the Office 2002 PIAs onto your development machine, and then reference the Excel 2002 PIAs for your project. When testing, you would be running Excel 2003 while your program is referencing the 2002 PIAs, but the PIAs know how to automatically upgrade themselves, so Excel 2003 would actually be running with the Excel 2003 PIAs, if available on your machine.

In short: I would try installing the 2002 PIAs on your machine, reference those instead of the 2003 PIAs, and this should run on both your development machine and on your target machine. (The target machine would need the 2002 PIAs installed as well.)

Untested, but I think that this should work. I've got my fingers crossed for you. Let us know how it goes...