Anders, I tried reversing the uninstaller’s action sequence as you suggested but nevertheless the assembly still remains in place in the winsxs store after the uninstaller runs on Vista. It is unclear what the issue with assembly reference counting on that OS is. I demonstrated with an Uninstall registry key reference because that seemed like the natural thing to do for an application that has a registry Uninstall key regardless of SxS deployment.
If the application doesn’t have such a key or name collision is feared, the opaque string method may be appropriate. Kobi, First of all, why would you write your name with an ‘i’?:-) And to the matter at hand, using Process Monitor to associate the installation I/O with TrustedInstaller would only indicate some form of out of process communication.
It would be intuition about behavior of Microsoft authored system components that may lead to the conclusion the actual IPC being used is COM. There’s also the option of looking at the IRP’s stack trace (if there’s a feature I really love in procmon it’s the stack trace for every IRP, amazing!) in the Process Monitor GUI and figuring out it originated from an RPC thread pool worker thread in the TrustedInstaller process. Anyway, in this case using a monitor is a good approach but in others there’s a lot of noise you have to filter to see what’s interesting. One purpose of the post is to directly deal with the issue of runtime deployment but another important one is to illustrate how you can dig into unknown components without fear to get the answers missing from the non-existing or lacking documentation. In that context, SxS is just a case study. Hi Koby, The SxS store architecture on Vista works a little differently than what most people would expect. When an assembly is Uninstalled, that doesn’t mean the files will necessarily be removed, it means that applications will no longer be able to bind to the DLLs in the store.
Effectively, the files are now invisible to applications (try binding to your Debug CRT assemblies to see) The actual physical files will be removed after a step called “scavenging”, which unfortunately can’t be controlled. Scavenging will happen occasionally, as a reaction to system updates through Windows Update (as to why, I hope to blog about one day).
I’ve found a way to distribute the VS 2008 SP1 libraries. You need to install both the SP1 CRT, as well as the policy, which redirects all bindings for 9.0.21022.8 to 9.0.30729.1. There’s also a problem with the.cat files; I had a different.cat file for the policy in my%WINDIR% winsxs manifests than the one in the merge module. Apparantly, only catalog files signed by “Microsoft Developer Platform Side-by-Side Assembly Publisher”, expiry will work, whereas those signed by “Microsoft Corporation”, expiry will not.
The Visual Studio Express IDE does have certain limitations compared to the professional version. One of these limitations is the lack of deployment options. Deploying an application is not a menial task - several things need taking care of, such as deciding what deployment software to use and determining the additional libraries your application needs to enable it to function.
To complicate matters even more, different libraries will be available on different systems. When the Visual Studio IDE is installed on the developer's system, it automatically installs all the libraries that.NET needs. So once that developer transports his executable to a system which hasn't that particular version of Visual Studio installed, chances are that the application will not execute and throw an error. This is because a.NET application requires a few extra library packages on top of the standard Windows libraries. In effect it needs 2 library packages:. A.NET Framework.
The particular version will depend on the version of Framework your project targets. This can be set in Visual Studio by going Project → Properties → Common Properties → targeted Framework. A Visual Studio Redistributable package. The version of this depends on the Visual Studio version your project is designed on. The deployment software needs to know if these packages reside on the user's computer, and if not, it will need to facilitate installment of these. Both the packages can be found in the system's Control Panel → Programs and Features.
You will find entries such as Microsoft Visual C 2008 Redistributable. And Microsoft.NET Framework.
(if they are available). Usually various versions of each package exist. I checked these packages on many Windows 7 computers during a recent stroll around a computer store, and they all seem to have the 2008 redistributable and the Framework 3.5 installed. So it pays to aim your development project to make use of these packages. I also found that the packages are installed on many XP and Vista systems. Is a professional open source system that creates Windows installers.
At first, its script language seems a bit tedius, but it is very powerful and there are many examples on the net. Tedious is a bit of an understatement, I do find the NSIS scripting actually quite perplexing, especially its use of stacks and labels - normally low level mechanisms - which is odd for a scripting language. Also, creating pages is quite confusing, but the potential is certainly there, as can be learned from the many sophisticated examples on the web.
Vcredist X86 Download
The is a free NSIS editor and includes a GUI editor to create pages. This facility is (confusingly) located in the editor's File → New Install Options File It is easy to get lost in the countless articles and webpages on NSIS. Reading the documentation that comes with the software and running its examples provides a good first step. I encountered a Side-by-side Error when trying to execute one of my applications on a different system. Here's a clear explanation of Side-bySide from Wikipedia: A common issue in previous versions of Windows was that users frequently suffered from DLL hell, where more than one version of the same dynamically linked library (DLL) was installed on the computer. As software relies on DLLs, using the wrong version could result in non-functional applications, or worse.
Windows XP solved this problem for native code by introducing side-by-side assemblies. The technology keeps multiple versions of a DLL in the WinSxS folder and runs them on demand to the appropriate application keeping applications isolated from each other and not using common dependencies. Quoted from Wikipedia: From the Microsoft MSDN website: A side-by-side assembly contains a collection of resources - a group of DLLs, Windows classes, COM servers, type libraries, or interfaces - that are always provided to applications together. These are described in the assembly manifest.
Quoted from MSDN: From XP systems onwards, the shared components of side-by-side applications are located in a huge (5 GB +) folder, named WinSxS ( SxS being an acronym for Side-by-Side). It is the biggest systems folder on your computer. When the system throws an error, a log file is automatically created. This file can be read by going to Control Panel → Administrative Tools → Event viewer → Windows Logs → Applications. Just clear the panel and start the executable that throws this error. Reopen the System Viewer and one or more errors should appear.
Double click on an error message to view the details. But you can do a more detailed analysis using a system tool called sxstrace:. run in the command line: sxstrace trace -logfile:sxstrace.etl. run your app and click OK in the Error Message. stop tracing by pressing Return in the command line. convert the binary error file to txt: sxstrace parse -logfile:sxstrace.etl -outfile:sxstrace.txt Another tool that proved most useful of all is the Dependency Walker which can be freely downloaded from.
The application is called depends.exe. Use it as follows:. start depends.exe. drag your application into it.
profile. save as dwl file and read. right click the module and select full paths See also As it turned out in my case, depends.exe allerted me to the fact it couldn't find msvcrtd.lib. I solved this by adding the following lines in Visual Studio's project command line properties ( project → Properties → command line): /NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:libct.lib /NODEFAULTLIB:libcd.lib /NODEFAULTLIB:libcmtd.lib /NODEFAULTLIB:msvcrtd.lib.
Hi, I want to know if there is any way to specify the location of the files installed by vcredistx86.exe(downloaded from MS website). Right now it is installing all the files in c: I use the following command line to do a silent install: 'vcredistx86 /q'. I use this in an NSIS script(Null Soft installer script). Ideally I would like it to install the files in system folders or atleast in a sub-folder in my App's folder. My App is written in Visual Studio 2008(VC).
I'm testing this on Windows XP. Thanks Rajeev.
Hello Rajeev, Thanks for your post. Hans and Sheng is right. We cannot install the VC redistributable in to other folders, otherwise, applications which depend on VC runtime libraries will not run correctly because they cannot find these libraries. And the files extracted into the root of C: are the installer files, the are temporary files and usually will be removed after vcredist is correctly installed. If they are not removed, you can delete them manually.
Nsis Install Vcredist_x86.exe
Both have the same description in the file property (which is 'Microsoft Visual C 2008 Redistributable Setup'). Its confusing to see so many versions of the same file with the same name when searching for it on the MS website. Yes, they are both Visual C Redistributable package, but they are for different version of Visual C. In fact, version 9.0.21022.8 is for Visual C 2008, while, version 9.0.30729.17 is for Visual C 2008 SP1. Thanks, Rong-Chun Zhang in Forum If you have any feedback on our support, please contact msdnmgatmicrosoft.com Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have any feedback, please tell us. Hi Hans, I'm testing on WindowsXP fresh install in a virtual machine.
I'm now running vcredistx86.exe directly from explorer(double clicking). After the install I see the following files in c: eula.1028.txt eula.1031.txt. Globdata.ini install.exe install.ini install.res.1028.dll install.res.1031.dll.
VCRED.cab VCRED.MSI vcredist.bmp 24 files in all. Are these the files that should go into c: windows winsxs as you mentioned? Uninstalling the redistributable removes these files.
I see the same behaviour on Windows 7 in a virtual machine. How do I specify where to locate these files? I don't want to dump all of them in the user's c: Thanks Rajeev. I have downloaded another version of vcredistx86 from the MS website.
Looking at the File Version in the file properties for this shows it as 9.0.30729.17. This one works fine and doesn't create any files in c: The earlier file that I used showed File Version to be 9.0.21022.8. Both have the same description in the file property (which is 'Microsoft Visual C 2008 Redistributable Setup'). Its confusing to see so many versions of the same file with the same name when searching for it on the MS website.
Hopefully this will fix my problem. Thanks to all who replied. Hello Rajeev, Thanks for your post. Hans and Sheng is right. We cannot install the VC redistributable in to other folders, otherwise, applications which depend on VC runtime libraries will not run correctly because they cannot find these libraries.
And the files extracted into the root of C: are the installer files, the are temporary files and usually will be removed after vcredist is correctly installed. If they are not removed, you can delete them manually. Both have the same description in the file property (which is 'Microsoft Visual C 2008 Redistributable Setup'). Its confusing to see so many versions of the same file with the same name when searching for it on the MS website. Yes, they are both Visual C Redistributable package, but they are for different version of Visual C. In fact, version 9.0.21022.8 is for Visual C 2008, while, version 9.0.30729.17 is for Visual C 2008 SP1. Thanks, Rong-Chun Zhang in Forum If you have any feedback on our support, please contact msdnmgatmicrosoft.com Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
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. 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.
Nsis Install Vcredist_x86 Download
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.
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.
Nokia navifirm free download dct4. 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.