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
- :
- DFS Issue - Creating App-V Package
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
‎Sep 22, 2010
03:11 AM
DFS Issue - Creating App-V Package
Hi,
To support AdminStudio / InstallShield use in multiple countries we have localised shares where our project files are stored, linked together using a DFS structure.
When we configure the ISM project to build an App-V package, if we are running from a first level DFS link thats been setup directly below the DFS root, then it works fine, however if the link is lower down second level or below then it fails to compile the App-V SFT file, giving a -10003 error for every file in the ISM project.
I've attached a screen shot to visualise the above, when run from the FirstLevel folder it will work fine, but the SecondLevel folder gives the -10003 errors.
Both DFS links are targetting exactly the same files on exactly the same "real" share.
Cheers,
Craig
To support AdminStudio / InstallShield use in multiple countries we have localised shares where our project files are stored, linked together using a DFS structure.
When we configure the ISM project to build an App-V package, if we are running from a first level DFS link thats been setup directly below the DFS root, then it works fine, however if the link is lower down second level or below then it fails to compile the App-V SFT file, giving a -10003 error for every file in the ISM project.
I've attached a screen shot to visualise the above, when run from the FirstLevel folder it will work fine, but the SecondLevel folder gives the -10003 errors.
Both DFS links are targetting exactly the same files on exactly the same "real" share.
Cheers,
Craig
(10) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 22, 2010
11:55 AM
I don't believe there is anything in particular we'd be doing that would make one of these scenarios work while the other does not -- we certainly don't target (or disallow) DFS directly. Perhaps something might show up in a comparison of two ProcessMonitor logs - one working and one failing - that might help diagnose the situation. (Of course teasing the relevant information out of what will be a huge log with different filenames may be really tedious.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 23, 2010
07:09 AM
I've already run a ProcessMonitor log in an attempt to diagnose this problem.
I can see during the build the MSI is extracted to C:\TMP\[AS]\[RandomNumber] along with all the source files. That part works from both DFS paths.
However at some point the extracted source files are copied back to the location the ISM is located on the DFS share under the App-VPackage sub folder ready for compressing into the SFT file.
That's the part thats failing when the ISM is located in a DFS path thats not linked at the root level, but the ProcessMonitor log doesn't show any useful data regarding the transfer back to the network.
I've tried it from different OS's (XP 32 and 64bit, and W7 64bit) and also different DFS root hosts (domain or standalone hosted) and its producing the same behaviour.
Cheers,
Craig
I can see during the build the MSI is extracted to C:\TMP\[AS]\[RandomNumber] along with all the source files. That part works from both DFS paths.
However at some point the extracted source files are copied back to the location the ISM is located on the DFS share under the App-VPackage sub folder ready for compressing into the SFT file.
That's the part thats failing when the ISM is located in a DFS path thats not linked at the root level, but the ProcessMonitor log doesn't show any useful data regarding the transfer back to the network.
I've tried it from different OS's (XP 32 and 64bit, and W7 64bit) and also different DFS root hosts (domain or standalone hosted) and its producing the same behaviour.
Cheers,
Craig
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 24, 2010
07:46 AM
I downloaded a trial of InstallShield Professional 2011 with the Virtualization Pack and that works from all DFS paths without any issues.
Unfortunately migrating to InstallShield Professional 2011 isn't a solution for us yet as we are using InstallShield Professional as part of AdminStudio (which is still 2010 based.)
So something in InstallShield 2011 resolves this issue that exists in 2010.
Unfortunately migrating to InstallShield Professional 2011 isn't a solution for us yet as we are using InstallShield Professional as part of AdminStudio (which is still 2010 based.)
So something in InstallShield 2011 resolves this issue that exists in 2010.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 29, 2010
03:31 AM
Has anyone got any ideas as to why this would work in InstallShield 2011 but not in 2010?
Thanks,
Craig
- Are there any differences in the way each deals with DFS paths?
- Does it extract the files in the MSI and compile the SFT any differently?
Thanks,
Craig
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 29, 2010
10:36 AM
I'll ask our App-V guy and see if he can clarify this. I don't believe we have any specific code changes (or just code itself) specific to DFS, but it wouldn't surprise me if we had a reason to change how we chose a temporary folder for extracting the MSI.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 30, 2010
04:19 AM
Any hints as to when the next version of AdminStudio (with InstallShield 2011 included) is due as through whatever mechanism it fixed our issue.
Thanks,
Craig
Thanks,
Craig
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 07, 2010
04:38 AM
Hi Michael,
Did you get any information out of the App-V guy?
Thanks,
Craig
Did you get any information out of the App-V guy?
Thanks,
Craig
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 07, 2010
10:10 AM
We talked about it a bit, and weren't able to figure out anything conclusive (not having a DFS environment set up to test things means it's pure conjecture). Perhaps the biggest (relevant) difference between these versions was a migration to VS2008. My understanding is several file primitives we used could be implemented completely differently in this version, which might explain the behavior change.
As for when you'll see that in AdminStudio? There's a chance the DLL could be dropped in, but we really can't support that. I don't have date information, but in general I was under the impression that there's up to about a six month lag between IS releases and AS releases that consume it. Does that sound like what you've seen previously?
As for when you'll see that in AdminStudio? There's a chance the DLL could be dropped in, but we really can't support that. I don't have date information, but in general I was under the impression that there's up to about a six month lag between IS releases and AS releases that consume it. Does that sound like what you've seen previously?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 08, 2010
09:39 AM
Hi Michael,
Thank you for that. 6 months sounds fairly typical to what's happened before. Your post inspired me to try a number of the DLL's from the IS 2011 System folder in the IS 2010 System folder.
The VirtConv.dll file alone seems to do the trick and fixes the problem and the resulting App-V package functions okay. Not sure what the long term impacts are and I realise its not officially supported but at least we have a workaround.
Thank you for your help.
Cheers,
Craig
Thank you for that. 6 months sounds fairly typical to what's happened before. Your post inspired me to try a number of the DLL's from the IS 2011 System folder in the IS 2010 System folder.
The VirtConv.dll file alone seems to do the trick and fixes the problem and the resulting App-V package functions okay. Not sure what the long term impacts are and I realise its not officially supported but at least we have a workaround.
Thank you for your help.
Cheers,
Craig
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2010
02:44 AM
Although the updated VirtConv.dll seems to work okay now with DFS paths we've now hit the dreaded 255 character path limit issue.
It's fairly easy to hit on a defined DFS structure as the App-V extracted files make the path even deeper than it already is.
There are updated API's in Windows that can be used to prevent the 255 path limit becoming an issue but I imagine this would mean InstallShield would need to be recoded.
It's fairly easy to hit on a defined DFS structure as the App-V extracted files make the path even deeper than it already is.
There are updated API's in Windows that can be used to prevent the 255 path limit becoming an issue but I imagine this would mean InstallShield would need to be recoded.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)