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 CA, XCopyFile and network path issue
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
‎Apr 24, 2008
01:27 AM
Deferred CA, XCopyFile and network path issue
Hello,
I have Basic MSI setup where the requirements is to place some files beside setup itself (some files that can be customized after the kit was built).
During installation I have to copy these files from the location where setup runs to the proper location in the target machine. To do this I added a InstallShield Install Script CA in the Execute sequence.
This CA run fine if it is not a deferred CA. If I made this CA deferred in system context, then it works fine only if the setup runs from local machine. If it runs from a network path, XCopyFile fails with error code: -2147024894 (System cannot find the file specified). All paths are obtained correct in deferred CA (I see this in the logs and one point is that it works fine from local machine) so this is not the issue.
The issue is that the XCopyFile cannot access the network path. Trying ChangeDirectory to the network path also fails.
From the docs I read deferred CA can runs with different credentials as the rest of the setup. Is this true? It can explain my problem.
Is there anybody that can suggest me a solution/workaround and keeping this CA as deferred in system context?
A possible workaround is to copy these files in the %TEMP% folder with an immediate CA and delete them at the end of install. What do you think?
Thank you.
I have Basic MSI setup where the requirements is to place some files beside setup itself (some files that can be customized after the kit was built).
During installation I have to copy these files from the location where setup runs to the proper location in the target machine. To do this I added a InstallShield Install Script CA in the Execute sequence.
This CA run fine if it is not a deferred CA. If I made this CA deferred in system context, then it works fine only if the setup runs from local machine. If it runs from a network path, XCopyFile fails with error code: -2147024894 (System cannot find the file specified). All paths are obtained correct in deferred CA (I see this in the logs and one point is that it works fine from local machine) so this is not the issue.
The issue is that the XCopyFile cannot access the network path. Trying ChangeDirectory to the network path also fails.
From the docs I read deferred CA can runs with different credentials as the rest of the setup. Is this true? It can explain my problem.
Is there anybody that can suggest me a solution/workaround and keeping this CA as deferred in system context?
A possible workaround is to copy these files in the %TEMP% folder with an immediate CA and delete them at the end of install. What do you think?
Thank you.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 24, 2008
09:33 AM
That is correct - the "system context" deferred actions are generally run with different privileges and identities than the rest of the actions in an msi. I think the last option you mention is the only real way to handle this (short of getting network access to the system context), but you may want to tweak your implementation so that it copies to a temp folder from a deferred (not in system context) custom action just before the deferred (in system context) action copies it into the right place. You could make the second copy just move it, and then all you would need is a rollback action which would also delete it (as the commit case has been handled by the move).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 24, 2008
11:43 AM
Thank you Michel. This saves lot of time for me. And thanks for your suggestion related to previous action.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 24, 2008
03:47 PM
Michael, one more question.
If my deferred CA set as "in system context" runs as deferred (not in system context), then is there any chance to encounter problems with the installation (Vista, etc.)? I ask this because I want to avoid double copy same files, saving time.
As additional information, the setup runs only with administrator privileges (only administrators can run setup), installation is per-machine and the files copied are simple copied (not registered) and they are application specific files.
Thank you.
If my deferred CA set as "in system context" runs as deferred (not in system context), then is there any chance to encounter problems with the installation (Vista, etc.)? I ask this because I want to avoid double copy same files, saving time.
As additional information, the setup runs only with administrator privileges (only administrators can run setup), installation is per-machine and the files copied are simple copied (not registered) and they are application specific files.
Thank you.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 25, 2008
09:42 AM
The real question here is not so much whether they need to be registered, but what privileges the non-system context has. If you're guaranteed to have lauched the MSI from an elevated (administrator privileges) context, then the privileges for both these contexts are nearly identical, and it would be possible to do a direct copy (as well as any registration, if it were necessary). If the MSI can be launched as a non-administrator, and only acquires administrative privileges at the execute sequence, then actions which aren't in system context will execute with the original non-administrator privileges, and you would need to do a staged double copy. Don't forget that maintenance and removal are likely to launch this way, so if maintenance can install (or repair) these files from source, it may be necessary to go this route for Vista.
One more thing to check out is the DuplicateFiles or MoveFiles table (and of course the RemoveFiles table for the uninstall case). If the particular files which need to be copied can be described this way, then perhaps Windows Installer itself can figure out which context to use to read them, and you might avoid writing custom code. I've not tried a case like this myself, though, so no guarantees. 🙂
One more thing to check out is the DuplicateFiles or MoveFiles table (and of course the RemoveFiles table for the uninstall case). If the particular files which need to be copied can be described this way, then perhaps Windows Installer itself can figure out which context to use to read them, and you might avoid writing custom code. I've not tried a case like this myself, though, so no guarantees. 🙂