Which Registry Key should check for installation path

[master]

Which Registry Key should check for getting the installation path of MS Office. Currently I am interested only in MS-Excel path. Other paths (or registries) are also welcomed.

[MXP]

Why do you suppose there is such a key? As far as I know, there isnt. Even if there was, why do you suppose it should be the same in Office 97, XP, 2003, 2007, etc.?

[master]

I am making a program to read "ms excel" file. For this I am importing certain dlls and excel.exe file.

But the path of these files depends where the user has installed "MS Office". That path is also different according to the version. So how to know this path. That is why I am thinking to read it from registry.

[MXP]

Windows doesnt know where Excel is either. Only Excel knows where it is.

[Wizard]

When doing something that relies on another program it is not uncommon to (on the first run only) pop up a dialog asking the location of Excel (with the expected default already selected, of course).

[ventsyv]

Excel should be in the path no ? You should be able to find the installation directory under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Excel\InstallRoot\path

Obviously, you can have a different version of Office installed, so you might want to get all keys under Office and loop through those looking for Excel\InstallRoot\path sub-key.

[MXP]

Actually, I found a KB article for finding the installation path for Office XP, 2003, and 2007 (with other versions it looks like you're out of luck). I searched for "office installation path" using Live Search and it was the first hit.

Why would Excel be in the path environmental variable? Programs dont (shouldnt) simply add themselves to path. Besides, what if somebody starts your program with a modified path environment variable in which Excel is not present? As for that key, nice find but dont use it. Ever. I refer you to The long and sad story of the Shell Folders key as to why you should never use somebody else's registry keys. Using keys (or data in general) that you dont own and that are not guarenteed to work in the way they do now places a compatibility constraint on the actual owners of that key, that is, you are doing your best to ensure that somebody else will do work to ensure your app works in the future. This is a bad thing for you and for them.

Let's say you do use the key and your application becomes used by many people and lets say that the next version of Excel changes the location of this key. If your program isnt popular enough then the Excel team wont notice it during their own testing and your app will break when your customers install a new version of Excel. Now your customers are angry and they'll probably contact both you and Microsoft. Now the Excel team is angry because they are getting support calls for a problem they didnt create.

Let's say now that your program is popular enough that the Excel team does notice the issue during their own testing. Let's say that it's popular enough that it forces them to have to maintain the old registry key (similar to what happened in the sad story about the Shell Folders key). Now the Excel team is angry because they need to maintain something which they were trying to get rid of! You've subverted their ability to innovate.

I cannot stress enough: do not use data that you do not own and that is not documented as existing. The method in the KB article is ok to use since it is a document published by Microsoft explaining how to do what you want to do for Office versions XP, 2003, and 2007. Grepping data from the registry is not.

[ventsyv]

Well, the problem here is not that developers went and used the Shell Folders registry entry, it is that MS left in some half functioning piece of junk hack in their release code. And on top of that did not bother to document the fact that this was a hack that is not to be used.
If they put data in the registry they have to expect that people might be using it. If you don't want other people to touch those entries, don't publish them in the registry, use a private configuration file.

The GUIDs that you provide are version specific. The new version of Office will have a different GUID and will cause you app to fail. Not to mention that MS recommends reading the GUIDs from the registry.http://support.microsoft.com/kb/832672

The app will be designated compatible with Office 11 and older, there should not be any reasonable expectation that it would work with newer versions of Excel.

I as the developer of the app, will check MS's documentation before their new version of Office ships to see if the compatability of my app has not been broken. If that's the case, I'll write a patch, or include support for that version of Office in the next version of my app.

I have not checked to see if that registry key entry is documented or not. If it is not, then I agree it is probably a good idea to use some other way of getting the path. Still I don't think hard coding GUIDs is the way to go.

After some research I found this : http://support.microsoft.com/kb/240794
It seems there is pretty standard way of getting the GUID of the installed version of Office and use that to get the path.

[master]

Thanks, All of you!

I am thinking that "If my application depends on any other application then it will be compatible with few versions only" so I will make a setup that will be limited to work with the current version of Excel 2007 and I will release new version(or updater) for other versions of office suites.

[MXP]

Well, the problem here is not that developers went and used the Shell Folders registry entry, it is that MS left in some half functioning piece of junk hack in their release code.

You didnt read the article. Microsoft had to leave those keys in for compatability with software that was already written. Those companies were told during the development of Windows that those keys would exist and when those plans changed the keys were left in so that four programs would continue to work until they could be updated.

And on top of that did not bother to document the fact that this was a hack that is not to be used.

If it's not documented then there is no guarantee that it will behave in a particular way. Thus, to make no guarantee that something should behave in a particular way, dont document it. Documenting the hack is guaranteeing that it will work in a particular way (namely, the hacked way).

If they put data in the registry they have to expect that people might be using it. If you don't want other people to touch those entries, don't publish them in the registry, use a private configuration file.

That is, very unfortunately, the practicle expectation that must exist but as I've explained that fact creates more work in maintainence which could have been used in innovation instead. Putting settings within configuration files wont fix the problem either since people will start grepping those instead.

The GUIDs that you provide are version specific. The new version of Office will have a different GUID and will cause you app to fail. Not to mention that MS recommends reading the GUIDs from the registry.http://support.microsoft.com/kb/832672

Yes, they are version specific. If there is a documented way of getting those GUIDs programmatically then that's awesome. If the GUIDs listed in your other KB articles are the same type of GUID listed in mine then yes, such a method exists and it is implicitly documented. However, it looks like they are GUIDs refering to different things: the one from my KB article refer to the MSI component while yours refer to the ProgID. I've verified on this machine that the MSI GUID for Excel is differnt from the ProgID GUID for Excel. You'll need to find a different method of finding the MSI component GUID for Excel and perhaps it is documented in some KB.

The app will be designated compatible with Office 11 and older, there should not be any reasonable expectation that it would work with newer versions of Excel.

There wont be for you, but there will be for users. Users expect everything to just work and they get angry at any or all parties involved when they do not.

I as the developer of the app, will check MS's documentation before their new version of Office ships to see if the compatability of my app has not been broken. If that's the case, I'll write a patch, or include support for that version of Office in the next version of my app.

If you arent diligent enough to do this you cause the problems listed above. Part of this diligence is making sure that all users have updated.