I built a merge module (or six) in InstallShield 2008. We used these merge modules in our main product installer. We also distribute them to OEM customers. Everything works just fine in our main installer, and we've created a sample project in InstallShield to show customers how to use our merge modules. It's a very simple sample and it installs our product quite effectively.
Now since we support Visual Studio, we need to be able to provide an example .vdproj for our customers as well. I created a very simple Visual Studio deployment project, and it behaves quite differently. I've verified that there aren't any significantly different sequencing issues, yet the conditions on a few CAs are not being evaluated properly.
I have a condition that looks like
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.
very strange inconsistencies between IS and VS
Started by
Kelter
, Nov 22 2010 20:00
7 replies to this topic
Kelter
-
- Full Members
- 14 posts
Posted 22 November 2010 - 20:00
| CODE |
| (?ComponentName.ModuleID=3) AND ($ComponentName.ModuleID=2) |
In other words: If the component's state is Installed, and it's action is Absent (remove) then do the action. This action is scheduled near the DeleteServices action, and is therefore scheduled after InstallValidate. InstallValidate shows the following:
| CODE |
| MSI (s) (3C:88) [16:07:49:882]: Component: ComponentName.ModuleID; Installed: Absent; Request: Local; Action: Local |
Yet the action attempts to run.
During that custom action, i call MsiDatabaseOpenView, and that function fails with the code 6: "The requested lookup key was not found in any active activation context." This usually happens when querying for a value by key name, but I've verified that the specified keyname exists in the specifies table. This logic works properly in the InstallShield-built version of the package.
Can somebody suggest a possible cause for this weirdness?
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 22 November 2010 - 20:15
| QUOTE |
| Yet the action attempts to run. |
That's weird. What does the log say when it comes to your custom action?
Stefan Krüger
InstallSite.org twitter facebook
Kelter
-
- Full Members
- 14 posts
Posted 22 November 2010 - 20:31
perhaps that wasn't the best way to phrase it... it doesn't attempt to run, it actually run, but fails as described at the end of the post.
i was also going to aplogize for posting in the wrong subforum, but apparently this topic could belong in the basic msi, or in merge modules, or in vendor neutral.
i was also going to aplogize for posting in the wrong subforum, but apparently this topic could belong in the basic msi, or in merge modules, or in vendor neutral.
Kelter
-
- Full Members
- 14 posts
Posted 23 November 2010 - 15:46
update:
i might be wrong, but it seems like conditions that reference component states/actions are the ones that are mis-evaluated.
to ask the question(s) more directly:
1. is there some sequencing restrictions with regard to using the component state/action syntax in conditions noted in the OP?
2. is there some reason, other than the actual non-existense of a row in a table, why i might be getting the return value (6) for MsiDatabaseOpenView?
i might be wrong, but it seems like conditions that reference component states/actions are the ones that are mis-evaluated.
to ask the question(s) more directly:
1. is there some sequencing restrictions with regard to using the component state/action syntax in conditions noted in the OP?
2. is there some reason, other than the actual non-existense of a row in a table, why i might be getting the return value (6) for MsiDatabaseOpenView?
Edited by Kelter, 23 November 2010 - 15:51.
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 24 November 2010 - 10:49
After the component states have been set, the condition should work, I'd think.
Could you verify the component names including the appended module ID - in the component table and in the conditions - by opening the built .msi file in direct edit mode or in Orca/InstedEd?
Could you verify the component names including the appended module ID - in the component table and in the conditions - by opening the built .msi file in direct edit mode or in Orca/InstedEd?
Stefan Krüger
InstallSite.org twitter facebook
Kelter
-
- Full Members
- 14 posts
Posted 24 November 2010 - 23:07
I always worry about losing a typo in all these tables, so i literally cut the component names from the component table and paste them when building a condition.
Additionally, I have an InstallShield Basic MSI project which literally does nothing more than to import the merge modules in the same way as this Microsoft Visual Studio Installer project does. In both cases, I created the project, added the modules, and set the company name, product name, and installation path. Build them both, and one behaves this way and one behaves that way.
Additionally, I have an InstallShield Basic MSI project which literally does nothing more than to import the merge modules in the same way as this Microsoft Visual Studio Installer project does. In both cases, I created the project, added the modules, and set the company name, product name, and installation path. Build them both, and one behaves this way and one behaves that way.
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 25 November 2010 - 13:15
| QUOTE |
| I always worry about losing a typo in all these tables, so i literally cut the component names from the component table and paste them when building a condition. |
In some places, InstallShield automatically appends a module ID, in others it doesn't. That's why I asked you to verify what's actually in the built .msi file (as this might differ from what you see in the project for whatever reason)
Stefan Krüger
InstallSite.org twitter facebook
Kelter
-
- Full Members
- 14 posts
Posted 29 November 2010 - 19:06
Okay, so tracing through the data trail lead me to the following: the VSI project doesn't just search a repository for some file names when importing merge modules. I had moved the repository since initially creating the VSI project, so the msms that i was importing were 6 weeks old. The condition field was actually blank for the actions in question 6 weeks ago.
This explains alot. I'll post an update if that wasn't the only problem.
Thank you again for your help!!!!
This explains alot. I'll post an update if that wasn't the only problem.
Thank you again for your help!!!!