Check if MS Excel is installed

[mannis]

I need to automate the exporting of data in a listbox to either a tab delimited file or an excel spreadsheet. I need both because i will not know if excel is installed on all clients. Is there a way to check to see if excel is installed on a client machine through the excel object library?

[kleinma]

I need to automate the exporting of data in a listbox to either a tab delimited file or an excel spreadsheet. I need both because i will not know if excel is installed on all clients. Is there a way to check to see if excel is installed on a client machine through the excel object library?

well a simple attempt to create an excel object with error handling should tell you if its going to be possible on the system the app is on.. if it errors out, then write to the textfile, if not, then you write it to the excel file..

you could also check the registry for certain excel values, but the error catch method works just as well...

[Shaggy Hiker]

In .NET, you may very well need to know more than just whether or not Excel is installed. You also need to know about all that doggone Interop stuff.

Therefore, Kleinma's suggestion about error trapping isn't just 'good enough', it is actually superior. Any other technique, other than looking for the existence of the correct PIA's will not tell you whether or not you can use it.

[mannis]

Thanks for the replies. I am just finding out about the interop stuff. Can you give me a quick low down on how this will affect what i want to do with regards to writing data from a listbox into an excel spreadsheet. Thanks again.

[kleinma]

Thanks for the replies. I am just finding out about the interop stuff. Can you give me a quick low down on how this will affect what i want to do with regards to writing data from a listbox into an excel spreadsheet. Thanks again.

another note is it NOT ONLY matters IF they have excel... but the version can even matter. I don't know how much this comes into play for just simple output to excel, but it no doubt would require late binding in this case which is an option strict no-no. Early binding with office objects is really only practicle in 2 situations

1) you know every user will have the version of office you referenced
2) you make the version of office you referenced a requirement of your application

so you may have to just deal with turning option strict off and using late binding (which is a pain in the arse because you can't use intellisense) If you do this I recommend you put this code in a seperate module and keep option strict on in all the other parts of the app except for the one dealing with excel. I also recommend you code it with early binding so you can use intellisense on the objects, and when its all done, you change it to late binding and test it.

So your next response I guess will either be "Thanks" or "what is late and early binding"

[kleinma]

this thread will be of some interest if in fact you can use early binding for your release app and it will bind with office 2003

http://www.vbforums.com/showthread.p...53#post1995453

[mannis]

Thanks