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.
Related
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.
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'm trying to install visual studio 2013 into my windows 7 32 bit system. I've encountered the below error during installation
"This update package could not be opened. Verify that the update package exists and that you can
access it, or contact the application vendor to verify that this is a valid Windows Installer
update package."
Help me out
it is windows so i am guessing: the installer package is corrupt or follow this link: http://kb.eset.de/esetkb/index?page=content&id=SOLN561
try to make some md5 sums of your files and google for them.
Normally this issue will occur if you are having permission issue or compatibility issue.
For permission issue:
Right click on the executable and run it with run as administrator option and check.
If above is not working then check for the compatibility issue by following the steps below:
To Run the installation program in compatibility mode:
1. Right-click the installation file's icon.
2. Click Properties > Compatibility .
3. Select the compatibility mode for Windows XP.
4. Click OK .
5. Run the installation program.
After it's installed, run the program in Windows XP compatibility mode by doing the same with the installed program.
If you have an older application for Windows XP or Vista that doesn't run in Windows 7, you may be able to get it working properly by running the program in compatibility mode.
1. To begin, find the application or shortcut that is causing the problem, then right click on it and select Properties.
2. Then, select Compatibility from the tabbed menu at the top of the properties page:
3. Now, check the "Run this program in compatibility mode for..." box and select the OS you wish to emulate. For most applications, it will be Windows XP SP2. Once you are done, click OK.
4. When you next launch the application it should run under compatibility mode using the OS you selected. If it still fails to run correctly, try another OS selection in step 3 and try again.
I have a 32bit .NET app that uses the built-in MSI setup project in VS 2008.
It is deployed per-user using a GPO. This means it is installed on each computer the user logs on to. This way each user automatically gets the correct shortcut on their desktop.
All our workstations are Windows XP (32bit), but some of our users also log on to a terminal server (Windows Server 2008) which is 64bit. When they log on to the server and click on the shortcut, the msi installer launches (I think it's self-healing, changing the shortcut to Program files (x86) and they can use the application.
The problem is that when they log on to their workstation again and they click on the shortcut on their workstation, it immediately fails because the shortcut points to the Program files (x86) folder, wich doesn't exist on the XP machine.
I'd expect the MSI to self heal again to fix the shortcut. Can I force this to happen?
This is not supported by Windows Installer.
The automatic repair is performed only when Windows Installer detects a missing resource. Most likely the server machine cannot access some application files or registry entries, so it performs a repair which just happens to modifies the shortcut target. It's basically a coincidence.
Since the user account is roaming (the user can use it on multiple machines), the application should be installed in the user profile folder. Windows Installer provides AppDataFolder for this.
Using the user profile roaming folder will allow your users to access the application files correctly from any machine.
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.