This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Appsearch not working during an install Modify
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 29, 2014
04:53 PM
Appsearch not working during an install Modify
Hello, I am running into an AppSearch issue with an installer that I am working on and it appears there is no way to get around it that I can see.
I currently have a test installer that has two features. One installs an EXE and the other a merge module with some DLLs in it. The merge module does a AppSearch for a registry key, takes the path it finds and sets it to the install location for one of the DLLs. If on the first install I install all features, the DLL will go to the expected directory. If on the first install I just select the feature with the merge module, the DLL will go to the expected location. If on the first install I select just the feature with the EXE, then modify to install the feature with the merge module the DLL will then be installed into a folder under C:\.
Example:
AppSearch looks for path in registry and stores it in [DLLFINALLOCATION]
File path is set to install to [DLLFINALLOCATION]Test
If installed first time, DLL will be installed to: C:\Program Files\Application\Test
If installed from a modify, DLL will be installed to: C:\Test
Any help would be greatly appreciated.
I currently have a test installer that has two features. One installs an EXE and the other a merge module with some DLLs in it. The merge module does a AppSearch for a registry key, takes the path it finds and sets it to the install location for one of the DLLs. If on the first install I install all features, the DLL will go to the expected directory. If on the first install I just select the feature with the merge module, the DLL will go to the expected location. If on the first install I select just the feature with the EXE, then modify to install the feature with the merge module the DLL will then be installed into a folder under C:\.
Example:
AppSearch looks for path in registry and stores it in [DLLFINALLOCATION]
File path is set to install to [DLLFINALLOCATION]Test
If installed first time, DLL will be installed to: C:\Program Files\Application\Test
If installed from a modify, DLL will be installed to: C:\Test
Any help would be greatly appreciated.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 01, 2015
04:47 PM
When a merge module is consumed during the build it no longer exists as the table data from the module is literally merged into the MSI. This means the merge module isn't doing an appsearch, the MSI is. The merge module merely contributed rows to the AppSearch table and possibly others such as RegLocator, DrLocator, Signature and so on.
Realize that inorder to provent merge conflicts, primary keys in merge modules are "modularized" with the merge module guid found in the ModuleSignature table. This means that the property you think is called FOO is really FOO.SOMEGUID. This can have implications for table data authored in the MSI .ISM as FOO != FOO.SOMEGUID.
I'd need to look at your project in more details but that should give you an idea of what to look for to resolve this issue.
Realize that inorder to provent merge conflicts, primary keys in merge modules are "modularized" with the merge module guid found in the ModuleSignature table. This means that the property you think is called FOO is really FOO.SOMEGUID. This can have implications for table data authored in the MSI .ISM as FOO != FOO.SOMEGUID.
I'd need to look at your project in more details but that should give you an idea of what to look for to resolve this issue.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 05, 2015
10:06 AM
That much I knew. When looking at the log file for the MSI I was looking for the PROPERTY.GUID. But when following it through the log file, It starts out with the correct path and then for no reason reverts to "[INSTALLDIR]POPERTY/Test" and is no longer "[PROPERTY]Test". I thought this was simple and straight forward but I guess it isn't. IS hides all the GUIDs for the items that I am using so from what I can tell all is how it should be.
App Search gets path from registry, stores in PROPERY. File installs to path in PROPERTY. Adding the GUID to after the properties just makes the GUID disappear. So it looks like IS is handing all of that in the background but it is still not working.
App Search gets path from registry, stores in PROPERY. File installs to path in PROPERTY. Adding the GUID to after the properties just makes the GUID disappear. So it looks like IS is handing all of that in the background but it is still not working.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)