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
- :
- File not updating during upgrade
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 12, 2017
09:26 AM
File not updating during upgrade
This one's kind of hard to explain, so please bear with me.
I have a 2015 InstallScript MSI Project (MyProject) that has an executable (AppA.exe) that is compiled in Visual Studio to a folder called 'bin'. AppA.exe has a service that needs to be installed with it (AppA_Service). Now, if MyProject is installed on a 32-bit machine, AppA_Service has a dependency on a specific process (one that I can't edit or control) and if it's installed on a 64-bit machine, it has a dependency on a different process (which I also have no control over). AppA.exe is one of several executables in MyProject, however, AppA is the only one having this issue - and it's the only one set up this way...go figure).
In InstallShield, I created two components for it: AppA_x86 and AppA_64. They both contain the same file. That is, the Link To field is the bin folder. I set their conditions so that it will only install for that respective platform. It's worth noting that these two components have different Component Codes and Keys:
I then add both of these to the same Feature.
This seems to work fine for a first time installation. However, the problem comes when upgrading. Every other executable updates just fine. AppA.exe, however, does not. No errors or anything, it just doesn't upgrade.
Things I have tried that did not work:
[LIST=1]
Giving both components the same Component Code. I figured since only one gets installed...
Adding a Major Upgrade item with the current Upgrade Code and all earlier versions.
I looked thru the InstallScript stuff, but not seeing anything that can help.
Custom Actions
I also got it down to one component, then wrote a script to update the registry when installing said component. It still did not recognize that it needs to upgrade that one executable.
I thought that a component was upgraded if the internal file's keys matched that of the key already installed. So if that's the case, shouldn't AppA.exe be updated? All of the other files update, just not this one. Is there something I can look for to determine how it decided not to update the file? Is there a way to force it to upgrade that executable no matter what?
Does anyone have any suggestions as to how I can make it so that I can get that executable to upgrade? If this is a stupid way of doing it, and there's a way to conditionally set a component services dependencies, please let me know.
Thanks in advance,
Scott
I have a 2015 InstallScript MSI Project (MyProject) that has an executable (AppA.exe) that is compiled in Visual Studio to a folder called 'bin'. AppA.exe has a service that needs to be installed with it (AppA_Service). Now, if MyProject is installed on a 32-bit machine, AppA_Service has a dependency on a specific process (one that I can't edit or control) and if it's installed on a 64-bit machine, it has a dependency on a different process (which I also have no control over). AppA.exe is one of several executables in MyProject, however, AppA is the only one having this issue - and it's the only one set up this way...go figure).
In InstallShield, I created two components for it: AppA_x86 and AppA_64. They both contain the same file. That is, the Link To field is the bin folder. I set their conditions so that it will only install for that respective platform. It's worth noting that these two components have different Component Codes and Keys:
Component: AppA_x86, Condition: NOT VersionNT64, Component Code: {ABC-123}, Key: AppA.exe
Component: AppA_x64, Condition: VersionNT64, Component Code: {DEF-456}, Key: AppA.exe1
I then add both of these to the same Feature.
This seems to work fine for a first time installation. However, the problem comes when upgrading. Every other executable updates just fine. AppA.exe, however, does not. No errors or anything, it just doesn't upgrade.
Things I have tried that did not work:
[LIST=1]
I thought that a component was upgraded if the internal file's keys matched that of the key already installed. So if that's the case, shouldn't AppA.exe be updated? All of the other files update, just not this one. Is there something I can look for to determine how it decided not to update the file? Is there a way to force it to upgrade that executable no matter what?
Does anyone have any suggestions as to how I can make it so that I can get that executable to upgrade? If this is a stupid way of doing it, and there's a way to conditionally set a component services dependencies, please let me know.
Thanks in advance,
Scott
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 12, 2017
02:07 PM
It sounds like you are authoring a 32-bit installer because you say "if MyProject is installed on a 32-bit machine" . Is that correct? If so, a 32-bit installer doesn't know about the 64-bit locations for file and registry.
A person cannot run a 64-bit installer on a 32-bit system, of course. So, if you are using a 32-bit installer then you are constrained to 32-bit components.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367425(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367430(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367451(v=vs.85).aspx
Of special note is this information
Windows Installer runs as a service on computers using 32-bit or 64-bit Windows. Versions of the installer earlier than version 2.0 can install and manage 32-bit Windows Installer Packages only on 32-bit operating systems. Note that you cannot advertise or install a 64-bit application on a 32-bit operating system.
A Windows Installer package must be specified as either a 32-bit or a 64-bit package; it cannot be specified as neutral. On a computer using a 64-bit operating system, the Windows Installer service is hosted in a 64-bit process that installs both 32-bit and 64-bit packages. Windows Installer installs three types of Windows installer packages on a computer running a 64-bit operating system:
•32-bit packages that contain only 32-bit components.
•64-bit packages containing some 32 bit components.
•64-bit packages containing only 64 bit components.
So, in a nutshell it almost sounds like the Compiler is not catching this problem, but I'd wonder if you did the full ICE validation if it would find the issue or not.
Why they don't turn on full ICE validation following a build is a bit odd. Other authoring tools I've used take the opposite approach and enable full ICE validation out of the box.
A person cannot run a 64-bit installer on a 32-bit system, of course. So, if you are using a 32-bit installer then you are constrained to 32-bit components.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367425(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367430(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367451(v=vs.85).aspx
Of special note is this information
Windows Installer runs as a service on computers using 32-bit or 64-bit Windows. Versions of the installer earlier than version 2.0 can install and manage 32-bit Windows Installer Packages only on 32-bit operating systems. Note that you cannot advertise or install a 64-bit application on a 32-bit operating system.
A Windows Installer package must be specified as either a 32-bit or a 64-bit package; it cannot be specified as neutral. On a computer using a 64-bit operating system, the Windows Installer service is hosted in a 64-bit process that installs both 32-bit and 64-bit packages. Windows Installer installs three types of Windows installer packages on a computer running a 64-bit operating system:
•32-bit packages that contain only 32-bit components.
•64-bit packages containing some 32 bit components.
•64-bit packages containing only 64 bit components.
So, in a nutshell it almost sounds like the Compiler is not catching this problem, but I'd wonder if you did the full ICE validation if it would find the issue or not.
Why they don't turn on full ICE validation following a build is a bit odd. Other authoring tools I've used take the opposite approach and enable full ICE validation out of the box.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 12, 2017
02:28 PM
This is also another good thing to know.
The installer sets the VersionNT64 property to the version number for the operating system only if the system is running on a 64-bit computer. The property is undefined if the operating system is not 64-bit.
So, assuming your installer is a 32-bit installer then the property you are trying to use is undefined.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372497(v=vs.85).aspx
The installer sets the VersionNT64 property to the version number for the operating system only if the system is running on a 64-bit computer. The property is undefined if the operating system is not 64-bit.
So, assuming your installer is a 32-bit installer then the property you are trying to use is undefined.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372497(v=vs.85).aspx
