How to manage order dependencies between AppSearch entries?


How to manage order dependencies between AppSearch entries?

In my case, I want a RegLocator to check for a path out of the registry and then I want Signature.Parent to use the path results of the RegLocator. Here's my implementation in tables...


Property Signature_
CSCORE FileSearchCsCore


Signature_ Parent Path Depth
FileSearchCsCore [INSTALLDIR] 0


Signature_ FileName Section Key Field Type
TeleFormIni TeleForm.ini TeleForm TeleForm Workstation Directory 0


Signature FileName MinVersion MaxVersion MinSize MaxSize MinDate MaxDate Languages
FileSearchCsCore cscore.dll 1033

With this authoring INSTALLDIR (resolved by the IniLocator) does not resolve by the time I need to use it in the DrLocator.Path


Unless the order is explicitly specified in the table via an "order" column or guaranteed through some method explained in the documentation, you should NOT rely on or assume any particular ordering within a table.

The concept of "order" in an MSI table is specious. MSIs are relational databases with no inherent order. Maintaining order in a table is not a guarantee of the MSI file format, and therefore any operation that touches the MSI file is perfectly within its rights to completely reorder the rows in the table inside the file. Simply opening and closing the MSI file could reorder the rows, as could "save as...", or poking the summary info, to say nothing of any operation that actually updates table data such as patch application or transform customization. Even then, nothing in the MSI SQL engine guarantees a particular retrieval order unless the SQL statement includes an ORDER BY clause. And nothing says Orca has to show the rows in a particular order either, unless you've sorted on a column and even that is merely a UI change. In fact there are scenarios where Orca does NOT show things in the order retrieved from the database.

Do not try to reverse engineer the behavior of the table processing. It could work fine by pure luck for months or years and then your third patch causes things to go crazy - you'll never know.

Off-line it was suggested to me that if there was specific sequencing required, one should use custom actions explicitly sequenced in the appropriate sequence table.

Editorial Clarification

MSI MVP Stefan Krueger pointed out that the original post (without the tables) did not make sense in the light of MSDN article Searching for a Directory and a File in the Directory. After reading through the original query, the code and the SDK, I believe pinpointed the problem in the authoring. One can't use the value of the Property but one can connect the dots using the Parent column and pointing it to the earlier Signature_.


Signature_ Parent Path Depth
FileSearchCsCore TeleFormIni 0

Content credit also belongs to

  • Chris, Microsoft Dev and former MSI Dev. You can get other Chris insights about developing for Windows Installer from the old Windows Installer Chat Archives

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at

Comments (2)

  1. Searching for a Directory and a File in the Directory ( seems to suggest that you CAN defined dependencies between searches. In this sample it will first search for the Folder, then use the result to search for a file in that folder. Specifying the signature of the first search in the Parent column of the second search seems to do the trick. Or am I misunderstanding that sample?

  2. Hi,

    I’m hoping the Windows Installer team look further into problems similar to the above. Each request is a need that Windows Installer is not currently meeting. It would be nice (where possible) for Windows Installer to be updated to support more ordering. For example I doubt it would be very hard to add an ordering column to the "SelfReg" table (a common issue in posts).

    My 2 cents worth,

    Dennis Bareis

Skip to main content