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
- :
- Deferred custom actions
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
‎Dec 07, 2007
03:05 PM
XCopyFile and Program Files directory
I have up-converted a Basic MSI installer to InstallShield 2008. The installer contains InstallScript custom actions.
Previous installers have copied a license from the installation CD source directory into Program Files using the XCopyFile function.
I notice that license copy no longer works on Vista. And renaming a file in the Program Files directory also does not. The installer does not seem to have access to the Program Files directory.
Is this because we have not yet signed our setup.exe?
We have never signed our applications or installers. We are looking into it now.
HERE's the BIG QUESTION:
Would signing the setup.exe manage to get back our ability to access the Program Files installation directory with InstallScript and use XCopyFile to place something there. Or does Vista just not like Program Files to be messed with after the installation?
My boss seems to think that the issue is XCopyFile() itself, which is supposedly deprecated in Vista. But there is no "RoboCopy" function in InstallScript to take its place, which she thinks that we should use. I think that may be barking up the wrong tree, since file renaming also fails.
FYI, "Require Administrative Privileges" is set to Yes in the Summary Information Pane.
We get the "UnKnown Program is trying to Access" UAC error message. However, clicking "Allow" does not enable XCopyFile rights to Program Files.
It would be nice if we could get that message never appeared at all and copying to the Program Files directory were unproblematically restored.
***********
In the meanwhile, I am using an uncompressed feature/component to install the license file. People don't like that because it reduces some of the flexibility of the old license copy functionality (for example, we can't presently point to an earlier version of the program on the user's machine and copying an active license from the older version to the newer version). And they don't like the uncompressed directory structure on the CD image.
Previous installers have copied a license from the installation CD source directory into Program Files using the XCopyFile function.
I notice that license copy no longer works on Vista. And renaming a file in the Program Files directory also does not. The installer does not seem to have access to the Program Files directory.
Is this because we have not yet signed our setup.exe?
We have never signed our applications or installers. We are looking into it now.
HERE's the BIG QUESTION:
Would signing the setup.exe manage to get back our ability to access the Program Files installation directory with InstallScript and use XCopyFile to place something there. Or does Vista just not like Program Files to be messed with after the installation?
My boss seems to think that the issue is XCopyFile() itself, which is supposedly deprecated in Vista. But there is no "RoboCopy" function in InstallScript to take its place, which she thinks that we should use. I think that may be barking up the wrong tree, since file renaming also fails.
FYI, "Require Administrative Privileges" is set to Yes in the Summary Information Pane.
We get the "UnKnown Program is trying to Access" UAC error message. However, clicking "Allow" does not enable XCopyFile rights to Program Files.
It would be nice if we could get that message never appeared at all and copying to the Program Files directory were unproblematically restored.
***********
In the meanwhile, I am using an uncompressed feature/component to install the license file. People don't like that because it reduces some of the flexibility of the old license copy functionality (for example, we can't presently point to an earlier version of the program on the user's machine and copying an active license from the older version to the newer version). And they don't like the uncompressed directory structure on the CD image.
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 09, 2007
08:33 PM
Does your filecopy only fail on modify, or does it fail on install as well?
In modify mode, only custom actions scheduled for "Defferred Execution in System Context" actually execute as administrator.
In modify mode, only custom actions scheduled for "Defferred Execution in System Context" actually execute as administrator.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 11, 2007
03:17 PM
Thank you. I will check that out (deferred actions). It would seem to be something new in Vista installers, since the custom actions worked/work okay on XP and 2000.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 11, 2007
04:09 PM
I didn't answer your question.
The action fails on install.
I should probably point out that we have an Major Upgrade set, since modifications from the previous version of the Vista version are significant and require a Major Upgrade.
However, the failure of the two functions that try to access the ProgramFiles directory occurs when there is no prexisting installation on the computer.
So . . . the actions fails on first installation.
But I will try your suggestion and see whether it solves my problem.
The action fails on install.
I should probably point out that we have an Major Upgrade set, since modifications from the previous version of the Vista version are significant and require a Major Upgrade.
However, the failure of the two functions that try to access the ProgramFiles directory occurs when there is no prexisting installation on the computer.
So . . . the actions fails on first installation.
But I will try your suggestion and see whether it solves my problem.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 20, 2007
04:41 PM
Deferred custom actions seem to come too late in the process to access the MSI Property variables that I need in order to know WHERE to copy the license file. In other words, they seem to be off the end of the pier.
But I'm still guessing think that the issue is that we do not have a certificate with which to sign InstallScript (EXE and DLLs?) in our 2008 installer.
But I'm still guessing think that the issue is that we do not have a certificate with which to sign InstallScript (EXE and DLLs?) in our 2008 installer.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 20, 2007
05:44 PM
Actually, searching the documentation and these forums for "CustomActionData" will turn up examples of getting property values from deferred mode.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 21, 2007
07:12 PM
Thanks. I'll look into that deferred action issue. I haven't tended to need to use them.
The problem was that when I converted a DevStudio 9.0 project to InstallShield 2008, IS 2008 slapped an "Invoker" (Standard User) manifest on the EXE when what was needed was the default "Highest Available" in order for the LicenseCopy custom action to have access to the Program Files directory. Either that, or our program itself needs to access the license file in APP_DATA or COMMON_APP_DATA.
So, when converting from DevStudio 9.0, check the setup.exe pane for "Required Execution Level". It may be less than you want.
The LicenseCopy function has always been grouped with the file move actions in the installer and set as Immediate.
The problem was that when I converted a DevStudio 9.0 project to InstallShield 2008, IS 2008 slapped an "Invoker" (Standard User) manifest on the EXE when what was needed was the default "Highest Available" in order for the LicenseCopy custom action to have access to the Program Files directory. Either that, or our program itself needs to access the license file in APP_DATA or COMMON_APP_DATA.
So, when converting from DevStudio 9.0, check the setup.exe pane for "Required Execution Level". It may be less than you want.
The LicenseCopy function has always been grouped with the file move actions in the installer and set as Immediate.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 21, 2007
07:20 PM
The topic you presumably mean is:
"Obtaining Context Information for Deferred Execution Custom Actions"
"Obtaining Context Information for Deferred Execution Custom Actions"
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 21, 2007
08:13 PM
Here's an old newsletter tip on the topic that might be of use (PDF warning): http://www.macrovision.com/webdocuments/PDF/CustomActionData.pdf?link_id=productsTipsTricks.