Nsis Install Vcredist_x86
Hello, I'm having a problem installing 'Microsoft Visual C 2015 Redistributable (x86) - 14.0.23918' as a prerequisite. It seems that the installer tries to install the package even though it (or a later version) is already installed. The prereq installer then fails and the installer shows a warning message. This is expected I suppose, since according to this page, the 2015 redist packages have a different behavior, where they return an error to the caller in this situation.
It seems that the installer tries to install the package even though it (or a later version) is already installed. The prereq installer then fails and the installer shows a warning message. This is expected I suppose, since according to this page the 2015.
The problem is really to find out why the installer tries to install the package. Even though it's a 32-bit package, it seems that the installation conditions are sometimes looking at the 64-bit locations instead of the 32-bit ones. When looking for file SystemFoldermsvcp140.dll, it checks C: Windows system32 msvcp140.dll instead of C: Windows SysWOW64 msvcp140.dll. I'm attaching a zip file with a pdf document that describes the tests I ran, with a lot of screenshots. Below are my conclusions from the end of that document. The full project can be downloaded from Conclusions? 1.The VC redist packages are very buggy.
The x64 package deletes and overwrite the x86 package’s registry keys, and doesn't remove the x64 files from C: Windows system32. 2.The installer’s evaluation of conditions is also buggy. Looking at items 9-11 (in the pdf), it seems that the installer is actually finding the x64 files in C: Windows system32. And since these have version 14.0.23026, which is less than the minimum 14.0.23918, the installer tries to install the x86 redist package again.
After I manually delete the left-behind files, the installation conditions evaluate correctly again. 3.The Searches that I added for the 32-bit files seem to be evaluating wrong. If the minimum version is set to 14.0.23918 the searches fail, but if it is set to 14.0.23917 the searches find the 14.0.23918 version files. Best regards, Magnus Hyllander Attachments (1007.26 KiB) Downloaded 554 times.
Hi Magnus, I tested the scenario, but I couldn't reproduce the behavior. If the 'Microsoft Visual C 2015 Redistributable (x86) - 14.0.23918' software or a newer version is installed on the machine, the prerequisite is not installed anymore. Can you reproduce the problem on multiple clean machines? In order to see the results of the prerequisite's install conditions you can go in the 'Install Conditions' tab, select all those conditions and use the 'Evaluate.'
Also, I see that you checked the 'Install prerequisite if at least one condition is false' option and on the 'VerifyReadyDlg' dialog of your package, the 'VCRUN' property is displayed as empty (in the PDF file you sent), so this seems to be the reason why your prerequisite is launched for the installation again. Can you make sure that all conditions are met or choose the 'Install prerequisite if all conditions are false' option and see if the problem persists? Best regards, Eusebiu. Hi Eusebio, Thanks for your reply. I agree that changing the installation conditions so that all must fail might help, but I was reluctant to do that since the installation conditions were set by you (a predefined prerequisite in AI 13.0).
But even so, it wouldn't explain the issues I am seeing with how installation conditions and application searches are behaving in this situation. I have repeated the scenario on a clean Windows 10 Pro 64-bit virtual machine I use for testing. Now I have tried to simplify the tests and explain exactly the steps I take to reproduce the behavior.
This is what I am seeing: 1.When searching for files with app searches, it appears that the minimum version is not inclusive. This seems odd, especially since there is no option to make the search inclusive. 2.When installing a 32-bit prerequisite, in a 32-bit package, the installation conditions don’t search first for files in the 32-bit SystemFolder. Instead they seem to first search the 64-bit location (C: Windows System32), and then the 32-bit location (C: Windows SysWOW64). In short, installation conditions and app searches don’t work as expected, and they don’t produce consistent results either. Here, again, are the new projects and files I used to test: I hope I'm not completely out in the blue here, but I can't explain the results I'm getting. Best regards, Magnus Hyllander.
Hi, Just to follow-up on this issue, using Advanced Installer 13.2. I finally have something that works, this is my summary:. For the 2015 package, MS changed the behavior in two ways :. If the package is already installed, trying to install it again returns an error code. Previously it was just ignored.
A registry key was introduced that can/should be used to check if the package is installed. 32-bit and 64-bit packages create files and registry keys in different locations (WOW64). Advanced Installer by default creates three installation conditions for the 2015 redist package: the registry key and two files. If any of them are false, the install action is run. Advanced Installer 13.1 has a bug when evaluating the file installation conditions for a 32-bit package: it searches in the 64-bit folder before the 32-bit folder, which meant that the installation conditions could be fooled in different ways depending on which version of the 64-bit package was installed. This bug has been fixed in Advanced Installer 13.2. I have checked a lot of versions of the 2015 redist packages, and found that ALL 64-bit packages overwrite the registry keys of the 32-bit package on installation, and delete them on uninstallation.
I don't know if this is a feature or a bug, I can't find any error reports on the net. What this means though, is that the 32-bit registry key can't be trusted as an installation condition for the 32-bit package. My final solution is to delete the registry key installation condition, and just keep the two file conditions. Now that AI 13.2 evaluates the file conditions for 32-bit packages correctly, detection of the 32-bit package seems to work reliably. Best regards, Magnus Hyllander. Hi Magnus, Thank you for your analysis about the registry keys.
It was quite helpful. The problem I've encountered when using file conditions that only check one file (such as msvcp140.dll) and nothing else, is that I have now encountered several computers where an incomplete set of VC2015 DLLs are stored in the system32/syswow64 folder. For example, msvcp140.dll might be there, but mfc140.dll or mfc140u.dll might be missing. Obviously this is a bad state but I've seen this enough times in the wild that it can't be a fluke. Some third party applications the user has installed are individually installing DLLs and not using proper redistributables.
Nsis Install Vcredist_x86 Mac
In this case, it fails to install VC2015 due to the single file condition. What I really had to end up doing is file conditions for every file in the redist, that is concrt140.dll, mfc140.dll, mfc140u.dll, mfcm140.dll, mfcm140u.dll, msvcp140.dll, vccorlib140.dll, and vcruntime140.dll This only works if there is no entry for the redistributable in programs/features, since the error code you mention does occur when installing something that already exists. Note: the above is more of a general discussion about making a condition for redistributables, not anything specific to Advanced Installer (since IS uses the same condition msvcp140.dll), but I thought I'd mention this here as it might be useful. I can now present a definitive cause of problems triggered from a simple DLL existence check (such as msvcp140.dll). The Visual C 2015 merge modules! Yes, those pesky merge modules that Microsoft has been including for years. They are in C: Program Files (x86) Common Files Merge Modules The merge modules in question: MicrosoftVC140CRTx64.msm or MicrosoftVC140CRTx86.msm, once included in an installer, and then installed by the installer that includes them, will cause the Visual C 2015 redistributable EXE to never be triggered due to the simple DLL check done by the calling setup program (namely Advanced Installer, or similarly InstallShield, which coincidentally checks for the same DLL).
This is a problem, because the CRT msm's do NOT include MFC, AMP or OpenMP. You have to include separate merge modules for those (from the same folder).
So if your app relies on MFC, and some other app has installed the CRT via the merge modules, then you are going to be broken, once your app checks to see whether it needs the redistributable. So you are basically relying on other setups to be good citizens so to speak, by having them include all 4 msm, instead of just the CRT one. As soon as even one setup worldwide ships with just the CRT msm, you are screwed. So advanced installer should modify their pre-conditions to a more sophisticated check, not just checking for msvp140.dll. Another kind of 'protection' from this, is to switch to using the 4 merge modules in one's own app, instead of the EXE.
And reference counting seems to work. So maybe it's best to go back to the merge module approach. Your thoughts? Hi, Indeed, the CRT merge modules include DLL files that are used as a condition for the 'Microsoft Visual C 2015 Redistributable (x86)' prerequisite. However, the predefined conditions of that prerequisite also contain a registry entry condition that is not installed by the CRT merge modules. So, even if the DLL conditions passes, the registry condition will not pass and the 'Microsoft Visual C 2015 Redistributable (x86)' prerequisite will be required for installation. The only wrong case when that registry condition also passes, is the one described by Magnus in his last post (when both x64 and x86 prerequisites are installed, then the x64 one is later uninstalled).
In this case, the x86 prerequisite will be triggered again for installation, even if it is already installed (because that registry entry was removed during the uninstallation of the x64 prerequisite). Anyway, I think that manually uninstalling the 'Microsoft Visual C 2015 Redistributable (x64)' prerequisite is not a common scenario and you do not have to worry about this.
Of course, adding all 4 merge modules in the package is also a solution which you can use. Best regards, Eusebiu.