I have been pulling out what's left of my hair trying to install software that requires a C++ redistributable (2017 x86) using InstallShield lite.
To start with, I define a prerequisite To include the C++ redistributable. When a user attempts an install, the user interface always appears. Now this is not a real problem however, if the redistributable was already installed`or there is a newer version then it will fail with a message that it has failed and it wioll ask the user if he wants to continue or abort the installation. If he selects continue, the software installs fine. This is not very user friendly.
This happens despite the correct command line switches being used i.e. /q /norestart. If you do this at a command prompt manually, it operates as it should. In other words it installs it, or fails because it is already installed but tells the user nothing. This is the way it is supposed to work.
Now I tried doing this as a custom action at the end of the installshield script but then the install appears to hang on some machines and on others other errors.
Now the only clue that I can give, is that if I create an MSI installation, then it never prompts. However with a setup.exe install it acts as above. I have only been successful with the msi install if I am installing a 64 bit app. Never with a 32 bit app.
Can someone guide me as to what I am doing incorrectly?
Thanks
VCRedist: This C / C++ runtime (in various versions and flavors) is a pain indeed. I decided to write something up a while back to try to summarize a few things:
Wix per user installer to detect the Visual C++ 2015 Redistributable (please skim at least - not great, better than nothing I hope - deals mostly with detecting the presence of the runtime).
Merge Modules: Does Installshield Lite support merge modules? If so, you can install the VCRedist using merge modules instead of the VCRedist_x64.exe file. This is insufficient for UWP applications (the universal CRT) as explained in these links:
Redistributables for deploying C++ exe developed with Visual Studio 2015 on Windows 7
WIX merge c++ runtime
Do read the links directly above - they are quick reads.
Batch File: Another option would be to keep the VCRedist_x64.exe file separate from your main setup and to zip up your MSI and the VCRedist_x64.exe in a ZIP archive and put an Install.cmd batch file in there which will install the VCRedist first and then your MSI file? Not too neat - one would have to admit. I think you can make a self-extracting archive that would automagically invoke it, but I haven't done that in ages.
Just a mock-up batch file from link below (untested):
REM 1. Install VCRuntime
vc_redist.x64.exe /install /quiet /log "%temp%\Install_vc_redist_2017_x64.log"
REM 2. Install MSI
msiexec.exe /i MySetup.msi /L*v C:\MySetup.log /QN
Not sure about security fixes and that kind of stuff. Run Windows Update afterwards?
Security Fixes & Link to Download: There have been so many security fixes for this runtime, and it is usually installed on most machines, that I would frankly just link to the download of the latest version and have people install it themselves as a pre-requisite rather than bundling an obsolete version in my setup, but that isn't really sufficient unless your package is for corporate use only (in which case they prefer to install their own runtimes with full control).
Some Links (to find easily):
Command lines to install and uninstall silently the VC++ 2017 Redistribuables (installation command lines, untested by me)
The latest supported Visual C++ downloads (please check)
Microsoft Visual C++ 2017 Resitributable Package (x86) (please do read this)
How to prevent vc_redist.x##.exe (VS2017) from ambiguously failing due to pending reboot?
Visual Studio 2017 Installer Project - include VC++ 2015 Redistributable
There is always the WiX toolkit
Distributable Code for Microsoft Visual Studio 2017 (Includes Utilities, Extensibility, and BuildServer Files)
Mailbag: How to perform a silent install of the Visual C++ 2010 redistributable packages
Thanks for a comprehensive answer. I am sure it will help a lot of people. What I have found is that running vc_redist.x86 from the command line in quiet mode will indeed always work as it should. In other words, if it is not installed, it will be installed. If it is already installed or a later release is installed, it will just return with no complaints. That is not the case using InstallShield Lite 2018 (same for all previous releases).
However, there is a simple solution to get it to work as I found out. All one needs to do is to include the entry Hidden="1" in the behavior part of the PRQ file. So there will now be an entry that looks like this:
<behavior Hidden="1" Failure="4" Reboot="2"/>
This solves the issue. It no longer runs separately from the installshield installer with it's own GUI but rather the messages now appear in the menus in installshield and it operates exactly as if you ran it at the command line. No more errors.
Recently I switched from mingw to msvc compiler for my Qt app.
I am using Qt5.8. The msvc debugger is from the windows 10 kit (though I develop on Win7 and Win8.1) and the compiler from the vc++2015 build tools.
I can run the app locally, but I can't run it on a different, clean computer.
I know that I have to copy the compiler specific dll's to the application's executable directory. All the other dlls are found by windeployqt. Still I don't get it to work. I can't ship vc_redist packages the user has to install, due to the requirement to be able to load the app from a pendrive. On the dev machine there are several dlls of the same name, how can I figure out which ones are actually used by the compiled app?
Questionable dlls is especially api-ms-win-crt-runtime-l1-1-0.dll.
On the deployment I got those errors:
I also tried Dependency Walker and showed the full paths. I assume the first hierarchy level is the important one, that's why I've hidden deeper hierarchies. I am wondering why the full path shows the dir System32 because isn't this the 64-bit files folder?? I did not target any specific one but my app must be running on x86. Is this a misunderstanding?
EDIT
According to another question and this Microsoft blog update it worked for me when I additionally included all dlls from this folder C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86. There is also a file named ucrtbase.dll. I have no idea why DependencyWalker showed different ones.
You can use tools such as Dependency Walker to see which DLL is used by any other DLL or exe file.
Edit: You can also take a look at Determining Which DLLs to Redistribute on MSDN
Also you could use static linkage to link against the MSVC runtime (i.e use /MT switch instead of /MD (see https://msdn.microsoft.com/en-US/library/2kzt1wy3.aspx). However this would also mean rebuilding Qt, but it would also give you the opportunity to build a static version of Qt, meaning that you would not need to ship any DLL alongside your exe. You can find more info on Qt wiki: Build Standalone Qt Application for Windows
I have a problem with our executable. I'm running this C++ 32-bit executable on my Windows 7 64-bit development box that also has all those Microsoft applications (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office)...
And it's still running just fine.
Now I got the client installation of the very same program and was asked to test it with a clean Windows 7 installation. Thus I got one Windows 7 64-bit VMware and updated it to Windows 7 SP 1 (the very same version my developer box is tuning).
But while on my developer box everything is fine the program does not work with the VMware (30 days trial) box.
The x86 Dependency Walker is telling me that the following DLL files are missing:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
I googled for those API-MS-WIN-... DLL files and found they should actually already be part of Windows 7 (some sites claiming the belong to Windows 8 and Windows Server 2012 though).
I already tried the suggested fixes I found, which are:
running 'sfc /scannow'
installing Visual Studio 2008 SP1 runtime executables
But that didn't solve anything. :-(
Side note: My development box does not have them either, and does not seem to need them. For example, the user32.dll on my box does not link against one of those, while the installation on the VMware does.
Any idea on how to fix this issue?
I tried to find a suitable download / fix on the Microsoft pages, but I failed.
After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLL files reported missing by the Dependency Walker tool, namely those
* API-MS-WIN-CORE-...
type DLL files were not part of the actual problem.
In my case the registration of three OCX files was missing and after that everything was just fine, BUT Dependency Walker tool still listed all the very same DLL files as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with a newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.
This problem is related to missing the Visual Studio "redistributable package." It is not obvious which one is missing based on the dependency walk, but I would try the one that corresponds with your compiler version first and see if things run properly:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
I ran into this problem because I am using the Visual Studio compilers, but not the full Visual Studio environment.
Going to dare to inject a new link here: The latest supported Visual C++ downloads. Stein Åsmul, 29.11.2018.
I just resolved the same problem with C++ Qt 5 and Windows 7 64 bits with MSCVC 2012.
In the beginning I thought it was a MSVC/Windows DLL file problem, but as BorisP said, the problem was in my project dependencies. The key is "How to know your project dependencies in Qt 5?".
As I didn't find any clear way to know it (Dependency Walker didn't help me a lot...), I followed next the "inverse procedure" that takes no more than 5 minutes and avoid a lot of headaches with DLL file dependencies:
Compile your project and take the executable file to an empty folder: myproject.exe
Try to execute it, It will retrieve an error (missing DLL files...).
Now, copy all the DLL files from Qt (in my case they were in C:\Qt\Qt5.1.1\5.1.1\msvc2012_64_opengl\bin) to this folder.
Try to execute again, it will probably works fine.
Start to delete progressively and try every time your executable still works, trying to leave the minimum necessary DLL files.
When you have all the DLL files in the same folder it is easier to find which of them are not valid (XML, WebKit, ... whatever..), and consequently this method doesn't take more than five minutes.
I just resolved the same problem.
Dependency Walker is misleading in this case and caused me to lose time. So, the list of "missing" DLL files from the first post is not helpful, and you can probably ignore it.
The solution is to find which references your project is calling and check if they are really installed on the server.
#Ben Brammer, it is not important which three .ocx files are missing, because they are missing only for Leo T Abraham's project. Your project probably calls other DLL files.
In my case, it was not three .ocx files, but missing MySQL connector DLL file. After installing of MySQL Connector for .NET on server, the problem disappeared.
So, in short, the solution is: check if all your project references are there.
As mentioned, DCOMP is part of the VC++ redistributables (implementing the OpenMP runtime) and is the only truly missing component. All the rest are false reports.
Specifically API-MS-WIN-XXXX.DLL are API-sets - essentially, an extra level of call indirection introduced gradually since Windows 7. Dependency Walker development seemingly halted long before that, and it can't handle API sets properly.
So there is nothing to worry about there. You're not missing anything more.
A better alternative to find the truly needed DLL files that are missing (if that is indeed the problem) is to run Process Monitor and step backwards from the failure, searching for sequences of failed probes for a specific DLL file in all the system path.
I also ran into this problem, but the solution that seems to be a common thread here, and I saw elsewhere on the web, is "[re]install the redistributable package". However, for me that does not work, as the problem arose when running the installer for our product (which installs the redistributable package) to test our shiny new Visual Studio 2015 builds.
The issue came up because the DLL files listed are not located in the Visual Studio install path (for example, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist) and thus had not been added to the install. These api-ms-win-* dlls get installed to a Windows 10 SDK install path as part of the Visual Studio 2015 install (e.g. C:\Program Files (x86)\Windows Kits\10\Redist).
Installing on Windows 10 worked fine, but installing on Windows 7 required adding these DLL files to our product install. For more information, see Update for Universal C Runtime in Windows which describes the addition of these dependencies caused by Visual Studio 2015 and provides downloads for various Windows platforms; also see Introducing the Universal CRT which describes the redesign of the CRT libraries. Of particular interest is item 6 under the section titled Distributing Software that uses the Universal CRT:
Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLL files are necessary is different on different versions of Windows, so you must include all of the DLL files in order for your program to run on all supported versions of Windows).
This contribution does not really answer the initial question, but taking into account the hit-rate of this thread I assume that there are quite a few people dealing with the problem that API-MS-WIN-CORE- libraries cannot be found.
I was able to solve a problem where my application refused to start with the error message that API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL is not found by simply updating Visual Studio.
I don't think that my build environment (Windows 7 Pro SP1, Visual Studio Ultimate 2012) was messed up completely, it worked fine for most of my projects. But under some very specific circumstances I got the error message (see below).
After updating Visual Studio 11 from the initial CD-Version (I forgot to look up the version number) to version 11.0.61030.00 Update 4 also the broken project was running again.
This solved the issue for me:
Uninstall the Visual Studio 2010 redistributable package if you have it installed already, and then install Microsoft Windows 7 SDK.
I solved the problem. When I registered the OCX files, I ran it with the Command Window that had been executed as an administrator.
For anybody who came here, but with a Photoshop problem: my solution was to uninstall the MS VC++ redistributable first x86 and 64 both. Then install one appropriate to the Windows version and architecture (86 or 64).
Installation of SQL Server Management Studio 2014 on a freshly installed Windows 7 resolved this problem at our client after a two-day ridiculous battle.
I came here with this problem occurring, after trying a fresh Windows 7 OEM install, upgrading to Windows 10.
After some searching of Microsoft forums and such I found the following solution which worked for me:
Replace C:\Windows10Upgrade\wimgapi.dll with the one from C:\Windows\System32\wimgapi.dll
I suggest also checking how much memory is currently being used.
It turns out that the inability to find these DLL files was the first symptom exhibited when trying to run a program (either run or debug) in Visual Studio.
After over a half hour with much head scratching, searching the web, running Process Monitor, and Task Manager, and depends, a completely different program that had been running since the beginning of time reported that "memory is low; try stopping some programs" or some such. After killing Firefox, Thunderbird, Process Monitor, and depends, everything worked again.
I had the same problem. After spending hours searching on the web, I found a solution for me.
I copied the file combase.dll file (C:\Windows\System32) to the release folder, and it resolved the problem.
Just to confirm answers here, my resolution was to copy the DLL that was not loading AND the ocx file that accompanied it to the system32 folder, that resolved my issue.
I work on a machine with win 7 32bit on visual studio 2010.
I tried to run in release mode a code that work fine on other computer(win7 64bit), and the following message came up:
The program can't start because msvcp80.dll is missing...
I tried looking up at threads dealing with this problem. tried to install diffrent Redistributable runtime versions. tried to copy those files(msvcp80.dll,msvcm80.dll, msvcr80.dll) to the project dir. and some diffrent things I don't even realised what I'm doing.
maybe some other ideas?
OK
thanks for your answers.
before i started the project i confirm all the build dll are 32bit.
I work on a 'opencv' project and narrow the problem to this one: the only problem occurred on opencv_imgproc230 lib function (like cvtColor, GaussianBlur)' what cause me to check with the program above(the_mandrill's link) the includes at this dll. it's include(or point I guess) for msvcp100.dll what seems reasonable because i work on VS10 enviroment.but even though it's screams for msvcp80.dll what belongs to VS80 I think.
by the way, when i manually include (msvcp80.dll,msvcm80.dll, msvcr80.dll) it's screams:
"R6034 An application has made an attempt to load the c runtime library incorrectly..."
It's seems that it's need to tell him to work with the VS10 version(for this dll's/runtime library)
Install Dependency Walker and run in 'Profile' mode (f7) which will show you the dlls it's looking for and failing to find.
This just means that you link agains MSVC C runtime dynamically.
So you have to install the so called redist package.
msvcp80.dll -> VC 8 -> VS 2005
X86 – http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en
X64 - http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=en
The dlls where installed to a central place by the redisrt package and should be resolvable after installation.
Can you check to see if your dlls are 32bit ? Maybe you have the 64 bit versions.
See How can I test a Windows DLL file to determine if it is 32 bit or 64 bit?.
See this question.
You mentioned that you've installed the VC8 redistribute packages, but you may have missed the "correct" one.
You probably want: Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update
I'm working on a deployment project (Wix based) which is used to deploy an application to run with AutoCAD and create shortcuts of AutoCAD's acad.exe while passing its own argument.
To achieve this, there is a Custom Action dll (C++) which iterate through Autocad's registry keys and get the "acad.exe" location and create/update the shortcut using MSI Api methods in MyInstaller.msi at run time.
Problem:
On x64 bit OS like Windows 7, Custom Action is reading the proper 'acad.exe' location from registry i.e. C:\Program Files\AutoCAD 2010\acad.exe, and update the shortcut properties in msi at runtime. But when msi finishes creating shortcut, the path is converted to 32bit program files i.e. C:\Program Files (x86)\AutoCAD 2010\acad.exe, which actually doesn't exists.
My Work Around:
As my msi is 32bit (x86), so I created a separate Component with attribute Win64=Yes, and modified Custom Action to update/create shortcuts for this component. But still target path in shortcuts are being converted to C:\Program Files (x86).
I know if I convert my MSI for x64 OS, this might be solved, but at the present, I can't do such a big change.
Is there any way that a 32bit msi can create shortcuts containing paths of x64 OS?
Any help would be really be appreciated..
Thanks a lot.
You are swimming upstream against MSI on this one. (Although I can understand why. )
Officially MSI is never platform nuetral. I assume you are using a custom action to read the registry values because MSI's AppSearch/Reglocator will constrain you to the WoWSys64 node. After that, MSI will substitute even hard coded references to program files as part of an application compatibility approach ( basically microsoft assumes you didn't know what you were doing and that they know what you really meant to do ).
Unofficially- read this thread to find a hack that I figured out to work around this. The summary is I found that if you convert C:\Program Files\ to a short path ( C:\Progra~1 ) that MSI is no smart enough to figure out what you are referring to so it doesn't substitute the value.
http://www.joyofsetup.com/2010/03/27/wix-msbuild-v2-0-and-x64-systems/
Note, this a hack and there is no way of telling if Microsoft will 'fix it' in future releases. The only other approach I can think of is you to then not use the shortcut table and instead write custom actions to create the shortcuts for you.
If you don't want to swim against MSI, consider this workaround. Create a small 64bit EXE ( yes, you can deploy a 64bit or AnyCPU exe to Program Files x86 is a x86 MSI ) that acts as a front end launcher to AutoCAD. Make it query the registry table and find the file then launch it or display a message saying AutoCAD is unavailable if it can't be found.
If you do this you make your install far cleaner.
Ok I was able to solve it:
Problem was, 32bit MSI on 64bit OS, was converting paths (in shortcut table) to 32bit equivalent paths i.e. Our Custom Action dll was getting AutoCAD's path from 64bit registry key as C:\Program Files\AutoCAD 2010\ and then injecting this path to MSI's shortcut table and Directory table. But when MSI was writing the shortcut, it was converting it to C:\Program Files (x86)\AutoCAD 2010.
We can't have 64bit Components in 32bit MSI, but Vice Versa is possible i.e. We can have 32bit Components in 64bit MSI.
However, in my case, I have to use 64bit Components for shortcuts and other components would remain 32bit.
So I have converted my 32bit MSI to 64bit MSI adding Plantform=x64 in Package information. And declare the component as Win64=Yes.
And this solved my problem and now I'm getting proper paths in shortcuts.
Due to this, now I have 2 separate installer i.e. for each 32bit and 64bit respectively.
Best regards
Farrukh