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
- :
- Why is WIN64DUALFOLDERS Coming Into Play All Of A Sudden? Please HELP!!
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
‎Oct 17, 2018
05:28 PM
Why is WIN64DUALFOLDERS Coming Into Play All Of A Sudden? Please HELP!!
Hi All,
I hope someone can help me quickly. We have an old web app which was installed via a 32 bit package. It really didn't matter what architecture of the package was because everything in the package was directed to c:\inetpub\wwwroot, where there is no redirection of any kind.
Since I've had the problem I'll describe I've read that it may be problematic to upgrade software delivered via a 32 bit package with a 64 bit package (x64 in Template Summary Property). However, our initial release of our new product was delivered via a 64 bit package and there were no issues. The old app was removed and the new web app actually had some utilities sent to Program Files, which is the desired location.
Now we get to the problem. Our latest release, when used to upgrade the initial (32 bit package) application, has the above mentioned utility files redirected to Program Files (x86). There are also some new file that were supposed to go to a different area under Program Files, but end up in Program Files (x86).
WIN64DUALFOLDERS shows up in the log, but I do not know why. The package has x64 in the Template Summary Property in the template and all of the above mentioned components are marked as 64 Bit in the template as well. I've attached the log if anyone wishes to take a peek.
What is triggering or why is dual folders coming into play. What can I check between our first release of the x64 package and this latest package to see what might might have changed. I am totally stumped. I hope someone can lead me toward the light!!
Thanks in advance for any info or tips you can provide!
I hope someone can help me quickly. We have an old web app which was installed via a 32 bit package. It really didn't matter what architecture of the package was because everything in the package was directed to c:\inetpub\wwwroot, where there is no redirection of any kind.
Since I've had the problem I'll describe I've read that it may be problematic to upgrade software delivered via a 32 bit package with a 64 bit package (x64 in Template Summary Property). However, our initial release of our new product was delivered via a 64 bit package and there were no issues. The old app was removed and the new web app actually had some utilities sent to Program Files, which is the desired location.
Now we get to the problem. Our latest release, when used to upgrade the initial (32 bit package) application, has the above mentioned utility files redirected to Program Files (x86). There are also some new file that were supposed to go to a different area under Program Files, but end up in Program Files (x86).
WIN64DUALFOLDERS shows up in the log, but I do not know why. The package has x64 in the Template Summary Property in the template and all of the above mentioned components are marked as 64 Bit in the template as well. I've attached the log if anyone wishes to take a peek.
What is triggering or why is dual folders coming into play. What can I check between our first release of the x64 package and this latest package to see what might might have changed. I am totally stumped. I hope someone can lead me toward the light!!
Thanks in advance for any info or tips you can provide!
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 18, 2018
12:01 PM
UPDATE: This problem only appears to occur on Server 2012. All is fine when test is run on Server 2008.
The older application was not supported on Server 2016 so I don't think I have to test there. I may however as it may shine light on the fact 2012 is the sole culprit or partner in crime.
The older application was not supported on Server 2016 so I don't think I have to test there. I may however as it may shine light on the fact 2012 is the sole culprit or partner in crime.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 27, 2018
08:59 PM
Can anyone tell anything from the log?