Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Registry search and conditions


2 replies to this topic

stefanu

stefanu
  • Full Members
  • 2 posts

Posted 08 March 2009 - 20:55

Hello everyone.

I'm new to this MSI stuff, and I am a little confused, not being able to find the solution to a apparently a simple problem. I hope this is the place to post such a message.

First of all, I am creating the setup using the embedded Visual Studio 2008 tools.

This is what I am trying to do : I have a .DOT file (a MS Word template) that I need to be loaded automatically when MS Word loads up. This can be done by placing it in a specific folder within the MS Office folders.

I add a registry search to get the value of a key that points to the MSOffice folder and set the associated property MSOFFICE90PATH. Then I create a custom folder, and set the target as [MSOFFICE90PATH]\Startup. So far, so good. Everything's ok if the registry key is there.

Problem is that various MS Office versions will save the registry key at different locations, so I need to make additional searches and folders and only copy those files whose registry key exists, but I am unable to find out how such a condition can be set so that the folder is not copied there if the registry key is not found.

I simply do not know how to set a condition based on the existence of such a registry key.

Can please point me out to some solution ?

Thank you in advance.

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 09 March 2009 - 10:46

Office is a pain in this regard. The problem is not so much with installations with only one version but those which have been upgraded over time.

If you have Office 9, 10 and 11, for example, a simple search would turn up only one of those, leading to an incorrect location for your file-drop.

In scripts I've built, I detect the location of either EXCEL.EXE or WINWORD.EXE (on the basis that the overwhelming majority of Office installations will definitely have these installed). I do that by back-tracking through the file associations for .DOC or .XLS files since, that way, I can more or less guarantee that whatever version these files are associated with will be the version that the user is actually using.

For example, a .DOC will point to an entry 'Word.Document.[version_number]'. So, the script checks the '(Default)' value for 'HKEY_CLASSES_ROOT\Word.Document.[version_number]\shell\Open\command' which should point to the executable. I can then parse the executable name out of the returned data to get the installation path.

IMV, this is too complex an operation to perform with AppSearch so I'd be using a script in a Custom Action to seek out the location and then perhaps set a public property which your component(s) can then use.

Etiquette note:
You should delete your duplicate post in the forum.

Edited by VBScab, 09 March 2009 - 10:48.

- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

stefanu

stefanu
  • Full Members
  • 2 posts

Posted 20 March 2009 - 16:12

Thanks for the reply. I have managed to finally do this by creating a custom action DLL. Indeed it's way to complicated to handle differently.