I am making an InstallShield Basic MSI setup. It is outside of Visual Studio. I want to save a registry value only if it is 64 bit OS. See image:
How do I configure the setup project to save a registry value only if it is 64-bit?
Create a new component using Setup design option in left navigation pane. In Condition field, enter VersionNT64 for 64-bit operating system condition. Now back to registry option, check 'View Filter' option in upper middle section and select the component which you had created. Now create whatever registry you want to create. It will be created only on 64-bit OS at the time of installation.
You can condition the registry creation based on the VersionNT64 property.
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.
Related
I have a VSTO addin which will not install on 32bit machines. (the error popup on install is: "This installation package is not supported by this processor type. Contact your product vendor.")
The addin uses Installshield to do the install.
The application builds with "AnyCPU".
It seems to force to 64bit if anything within installshield references a 64bit. (eg I have registry entries for my addin which are its Description, friendlyName, LoadBehavior and Manifest. These are located in HKLM/Software (64bit)/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin)
I don't really know if this needed?
So my fix is to have two releases... where one doesn't have any 64bit registry references.
How would I fix this? I've been toying around with the notion of ditching Installshield LE and moving to vs2017 with some other installer...
I have a VSTO addin which will not install on 32bit machines.
Do you mean the addin is not loaded by Office? or the install package itself fails to install?
I'll assume the addin is not loaded. I don't know how installshield controls the the package components bitness, but I will try to provide an answer that you can apply to any tool, as long as the following options are configurable in the tool.
With MSI packages installing VSTO addins you need to make sure your registry entries end up in the right registry hive, based on the bitness of your installed Office version, not the one of the OS.
So, for machines with Office x86 you have these registry:
on x86 OS: HKLM/Software/Microsoft/Office/Outlook/Addins/myAddin
on x64 OS & 32-bit Office: HKLM/Software/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin
The two paths above represent a single configuration in your MSI. i.e. if you create a standard MSI that installs the standard x86 registry entries on a 32 bit machine that same MSI will automatically be redirected to Wow6432Node for a x64 machine and everything should work if that machine has a 32-bit office installed.
If you have a x64 machine with a 64-bit office than you need to force the installation of that registry outside of the Wow6432Node, i.e. directly under: HKLM/Software/Microsoft/Office/Outlook/Addins/myAddin
This can be done from a 32-bit MSI too, if you mark the registry MSI component as a 64-bit (don't know where this option is in IS but I am sure you can find it). This will force the OS to stop the redirection to Wow6432Node for those registry entries. And the MSI should also work on 32 bit machines, where this flag will be ignored.
However, you should know that marking the component as 64-bit in a 32 bit MSI package will trigger some ICE errors/warning.
These are located in HKLM/Software (64bit)/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin)
FYI, this is the 32 bit area of registry on a 64-bit machine, not the 64-bit one. Only 32 bit applications can read registry from this location.
I am facing an issue regarding registry key locations when trying to install msi in Administrator mode (i.e. msiexec /a msiname /qn).
Our application is 32-bit application. When I am trying to install it on 32-bit as well as 64-bit windows OS using switch 'i' , the 'Uninstall' key is added to desired location. i.e.
HKLM/Software/Microsoft/Windows/Currentversion/Uninstall/{ProductCode} - on 32-bit OS
HKLM/Software/Wow6432Node/Microsoft/Windows/Currentversion/Uninstall/{ProductCode} - on 64-bit OS.
but, when I try to execute the same msi in Administrator mode i.e. using switch 'a', on 64-bit machine, the 'Uninstall' key is added to . i.e.
HKLM/Software/Microsoft/Windows/Currentversion/Uninstall/{ProductCode}
i.e. it is not added under WOW6432node.
The issue with this is that when I uninstall the msi which I had installed using switch 'a' , the uninstall key is not deleted from registry (as it is being searched in WOW6432node but not found)
So, when I install the same msi next time, the 'EstimatedSize' key value keeps on increasing as the key was not deleted during previous uninstallation.
Due to this, in control panel, for my application, the size is displayed wrongly.
For debugging D3D9 applications enabling the DirectX 9 Debug Runtime is essential.
(The June 2010 SDK must be installed first.)
For 64-bit applications it can be enabled in the DirectX Control Panel (64-bit) by checking Use Debug Version of Direct3D 9.
Problem: It resets back to Retail when the control panel is closed, and basically doesn't do anything.
(The 32-bit equivalent works.)
Kjell Andersson found the answer:
The problem originates from a Windows 7 update that locked down the HKLM\Software\Microsoft\Direct3D registry key to a user named TrustedInstaller. This made the Administrator not having rights to update the settings in the registry key - thus not allowing us to switch to a debug version of Direct3D 9.
To fix this problem you have to follow this procedure:
Using regedit as an Administrator, go to the HKLM\Software\Microsoft\Direct3D key.
Select Permissions... from the context menu on the key.
Press the Advanced button.
Go to the Owner tab and select the Administrator as the owner. Apply the changes and close the Advanced settings.
Back in the Premissions dialog select the Administrators group and check Full Control. Apply changes and close dialog.
You are now able to start the DirectX Control Panel from the DirectX SDK June 2010 and switch to the debug runtime.
I have developed a 32-bit application (build for x86) which will later be deployed on a 64-bit machine. I have set some configuration in registry so when the application starts on a 32-bit machine there is no problem reading its value, but when deployed on a 64-bit machine I can not read the value properly as the path of the registry is changed. To make things clear,
on a 32-bit machine I have the registry entry as follows.
[HKEY_LOCAL_MACHINE\SOFTWARE\MyApplication\InstallationPath]
"folder"="C:\Program Files\MyApplication"
But when I look on a 64-bit machine, this is shifted to:
[HKEY_LOCAL_MACHINE\SOFTWARE\**Wow6432Node**\MyApplication\InstallationPath]
"folder"="C:\Program Files\MyApplication"
Inside my application I have to query the value of the installation path. The obvious thing I have done is query the value with the hardcoded string "HKLM\SOFTWARE\MyApplication\InstallationPath", but which is not valid for a 64-bit machine.
How do I overcome this problem?
I don't really understand your problem: the Wow6432Node is transparent from the caller's point of view.
That means the registry key HKEY_LOCAL_MACHINE\SOFTWARE\MyApplication\InstallationPath will be automatically mapped to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MyApplication\InstallationPath when accessed from a 32-bit application running on a 64-bit machine.
So your code should work out of the box.
Have a look at the REGSAM samDesired argument of RegOpenKeyEx and many of the other registry APIs.
The important one for you is KEY_WOW64_64KEY: "Indicates that an application on 64-bit Windows should operate on the 64-bit registry view. For more information, see Accessing an Alternate Registry View."
You can use that in a 32-bit app to force it to inspect registry keys in the "native" 64-bit areas on a 64-bit system. (You might want to check that you're running on 64-bit Windows and only pass the flag then; I'm not sure what it would do on a 32-bit machine. Pass zero for samDesired when you want the default handling.)
You shouldn't have to do anything special in your code. 32-bit applications transparently access the portion of the registry under Wow6432Node.
To convince yourself of this, launch the 32-bit build of regedit.exe (available under Windows\SysWOW64) and take look around the registry.
I have a setup which has been created using InstallScript MSI project type. This problem is encountered by our client and he wants a quick solution.
Let's assume I have initiated the installation from a path like
C:\Setup_V_1.0.0931.1
Inside this folder I have Setup.exe through which I will install the product. After installation or after some days pass I will change the path to:
C:\New\Setup_V_1.0.0931.1
and this time I want to modify the setup. Actually we are supporting 3 features: Server, Client and Service.
This time I want only Client and not Server. So I will click on the Setup.exe or click on Uninstallation Icon in the Startup Menu which will lead to Maintenance Mode there you have an option to Modify, Repair or Remove. I choose Modify and select the feature, but as the installation progresses, this error message will pop up:
Setup could not find a file on the specified path or Disk. Please check
that the proper disk is inserted or specify a new path. Unable to
locate file c:\New\Setup_V_1.0.0931.1\setup.msi
Then, another popup will be shown saying:
Error: 1706. No Valid Source could be found for product. The Windows
Installer cannot continue.
The next error message is:
Error: 1603. Fatal error during installation. Consult Windows Installer
Help (Msi.chm) or MSDN for more information.
But if I change the path to its original location, it works fine.
How can I solve this?
I event checked in this registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{Product-Key}
This key contains a lot of information inside InstallProperties. There is a key called InstallSource and its value is C:\Setup_V_1.0.3909.1\. Even after changing this value installshiled is still showing errors.
I found the same registry information for Uninstallation Information:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Product-Key}
In your properties change ReinstallMode (or maybe Reinstall I forget which) from omus to vomus
the v means cache your install, so it will put your .msi file in c:\windows\installer so it can be used later.
When installing a MSI, Windows Installer saves the original MSI path in registry (the InstallSource entry you mentioned). When running the MSI in maintenance mode, Windows Installer will use this path to find the installation data (CAB files).
When you move the MSI, the path stored in registry is no longer valid, so Windows Installer cannot find the installation data.
A possible solution is to use "Add or Remove Programs" or "Programs and Features" in Control Panel to modify the installation. This way the cached MSI is used.