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
- :
- InstallAnywhere
- :
- InstallAnywhere Forum
- :
- Error with components...I think
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 26, 2009
11:04 AM
Error with components...I think
Hi all, hoping that someone can help me with this.
I'm getting an error in the install phase of the setup, right after the uninstall files are placed on the system:
I have no idea what this means. It seems to be complaining about the first component that I have.
That component is a shared DLLs library that a number of different products share. All are ultimately installed in the same directory.
This is a Windows-only installer.
I have half a dozen product features (corresponding to each product the user can install) and then a number of components, some of them shared between features. The component that seems troubling is a shared component (marked in the IDE as Shared Component) and is attached to every product feature.
The 'Dependency' tab controls are all blank, I didn't know what to put here, maybe that is the problem?
Ideally, the user can install one, any or all of the products, and would always get the shared DLLs. I hope I'm doing this right to begin with, seems reasonable and seems like it should work.
I have also tried setting that component to 'Standalone' and the same thing happens, so I'm not sure what is going on here.
Thanks in advance for any help.
I'm getting an error in the install phase of the setup, right after the uninstall files are placed on the system:
java.lang.RuntimeException: attempting to check evaluated state before evaluation
at com.zerog.ia.installer.ComponentDependency.l(DashoA10*..)
at ZeroGjd.c(DashoA10*..)
at ZeroGjd.b(DashoA10*..)
at com.zerog.ia.installer.Installer.install(DashoA10*..)
at com.zerog.ia.installer.actions.InstallProgressAction.n(DashoA10*..)
at com.zerog.ia.installer.actions.ProgressPanelAction$1.run(DashoA10*..)
I have no idea what this means. It seems to be complaining about the first component that I have.
That component is a shared DLLs library that a number of different products share. All are ultimately installed in the same directory.
This is a Windows-only installer.
I have half a dozen product features (corresponding to each product the user can install) and then a number of components, some of them shared between features. The component that seems troubling is a shared component (marked in the IDE as Shared Component) and is attached to every product feature.
The 'Dependency' tab controls are all blank, I didn't know what to put here, maybe that is the problem?
Ideally, the user can install one, any or all of the products, and would always get the shared DLLs. I hope I'm doing this right to begin with, seems reasonable and seems like it should work.
I have also tried setting that component to 'Standalone' and the same thing happens, so I'm not sure what is going on here.
Thanks in advance for any help.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 26, 2009
02:03 PM
This is unreal.
Ok, so I've done 75 installations today with various combinations of deleting stuff from the 'install' tree, to narrow it down to the cause. :mad:
In my Install Visual Tree, I've basically got:
[USER_INSTALL_DIR]
...
[$USER_MAGIC_FOLDER_2$]
...
[$USER_MAGIC_FOLDER_4$]
...
[$USER_SHORTCUTS$]
...
[$INSTALLER_TEMP_DIR$]
...
It will WORK if I delete all the actions under every other group EXCEPT USER_INSTALL_DIR.
I have tried many combinations of deleting some or all of the other actions, and it always ends the same - the error above. So this leads me to believe that the error isn't caused by any one action in any of the magic folders, shortcuts or temp dir.
So basically, it will work if it's just this:
[USER_INSTALL_DIR]
If it is:
[USER_INSTALL_DIR]
and
[USER_MAGIC_FOLDER_4]
It fails.
If it is:
[USER_INSTALL_DIR]
and
[USER_SHORTCUTS]
it fails.
and so on, and so on, and so on.....This makes no sense.
And before you ask:
USER_MAGIC_FOLDER_4 and USER_MAGIC_FOLDER_2 and USER_SHORTCUTS are all set before the 'install' phase.
Maybe if a Dev could research the exception message:
"attempting to check evaluated state before evaluation"
That might help me narrow it down. I've googled and bing'd that string, with no matches what-so-ever.
Help! 😞
Ok, so I've done 75 installations today with various combinations of deleting stuff from the 'install' tree, to narrow it down to the cause. :mad:
In my Install Visual Tree, I've basically got:
[USER_INSTALL_DIR]
...
[$USER_MAGIC_FOLDER_2$]
...
[$USER_MAGIC_FOLDER_4$]
...
[$USER_SHORTCUTS$]
...
[$INSTALLER_TEMP_DIR$]
...
It will WORK if I delete all the actions under every other group EXCEPT USER_INSTALL_DIR.
I have tried many combinations of deleting some or all of the other actions, and it always ends the same - the error above. So this leads me to believe that the error isn't caused by any one action in any of the magic folders, shortcuts or temp dir.
So basically, it will work if it's just this:
[USER_INSTALL_DIR]
If it is:
[USER_INSTALL_DIR]
and
[USER_MAGIC_FOLDER_4]
It fails.
If it is:
[USER_INSTALL_DIR]
and
[USER_SHORTCUTS]
it fails.
and so on, and so on, and so on.....This makes no sense.
And before you ask:
USER_MAGIC_FOLDER_4 and USER_MAGIC_FOLDER_2 and USER_SHORTCUTS are all set before the 'install' phase.
Maybe if a Dev could research the exception message:
"attempting to check evaluated state before evaluation"
That might help me narrow it down. I've googled and bing'd that string, with no matches what-so-ever.
Help! 😞
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 26, 2009
03:07 PM
I believe I found the culprit.
My installer is for Windows, but has both 32-bit and 64-bit files. I had components for each architecture, and incorrectly (apparently :rolleyes: ) added the "Check System Architecture" rule to the 64-bit components to only work on a 64-bit system.
That caused the problem I decribed above.
I had actions in the Install tree that operated on those components, I assumed (incorrectly) that those actions would be ignored if the component wasn't enabled - and the component couldn't possibly be enabled on a 32-bit system, due to the rule.
...or not, I guess.
What is the correct course of action here? How am I supposed to have one installer work on 32-bit and 64-bit with distinct sets of components for each architecture? I thought I was doing it the right way, apparently not.
If I set rules on the components, don't those (or shouldn't they) superceed any actions that I might perform on them? I assumed that if the component wasn't even available on a 32-bit machine, that having a rule to operate on it would be harmless. Apparently not. Correct me if I'm wrong.
Thanks.
My installer is for Windows, but has both 32-bit and 64-bit files. I had components for each architecture, and incorrectly (apparently :rolleyes: ) added the "Check System Architecture" rule to the 64-bit components to only work on a 64-bit system.
That caused the problem I decribed above.
I had actions in the Install tree that operated on those components, I assumed (incorrectly) that those actions would be ignored if the component wasn't enabled - and the component couldn't possibly be enabled on a 32-bit system, due to the rule.
...or not, I guess.
What is the correct course of action here? How am I supposed to have one installer work on 32-bit and 64-bit with distinct sets of components for each architecture? I thought I was doing it the right way, apparently not.
If I set rules on the components, don't those (or shouldn't they) superceed any actions that I might perform on them? I assumed that if the component wasn't even available on a 32-bit machine, that having a rule to operate on it would be harmless. Apparently not. Correct me if I'm wrong.
Thanks.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 26, 2009
04:21 PM
Since I hate doing research on the web and finding threads with no resolution on many other forums, I will do the right thing and at least post what I've found here.
This error for me was definitely caused by using the "Check System Architecture" rule in a Component.
This is apparantly a no-no.
Even if every action I had associated with those components also had the same rules check, I still got the Java exception. So I guess the only solution is to put the architecture check on the action instead of on the component.
Lesson learned.
This error for me was definitely caused by using the "Check System Architecture" rule in a Component.
This is apparantly a no-no.
Even if every action I had associated with those components also had the same rules check, I still got the Java exception. So I guess the only solution is to put the architecture check on the action instead of on the component.
Lesson learned.
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)