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.
Related
If this is not the correct place to ask this, I apologize.
I use 7zip to create an installer package. Recently, my computer was updated, and I can no longer get it to work. I use a Windows Installer from Visual Studio 2010 to create the installation package, which I add to a file called setup.7z. I have confirmed that the files are archived correctly. I then call
copy /b 7zsd.sfx + config.txt + setup.7z setup.exe
which packages everything into a single file called "setup.exe". Clicking on this would start the installer.
After the update, I can still make the file, and it looks just fine. However, if I try to click on it, I get a message saying 7-Zip: Unsupported method.
I have 7-Zip version 18.05 (x86) installed. Honestly, I am not sure where I got the 7zsd.sfx file, but do remember having to hunt it down. It has no versioning, but was last modified on 7/13/2007. I don't know if the version matters, since you shouldn't need 7-Zip installed since this is a self-extracting file. However, it may be that the older version isn't able to unzip something zipped by a newer version.
I think the problem is in different versions of 7zip and 7zip.sfx used. Unfortunately SFX file is absent in most recent 7zip packages.
Here is link to 7zip_extra from some old version that has both SFX file and .bat file to create the installer.
Works fine for me.
Setup Tools: Why 7-Zip? There is a plethora of alternatives for creating (real) setups - and several are free: How to create windows installer (several links to tools for creating all kinds of setups). Brief descriptions below as well - under "Alternatives" (free tools, or tools with free features). These tools have been tested extensively to ensure running with minimal dependencies. Just something to keep in mind and evaluate I guess.
7-Zip
Guess: first install the C/ C++ runtimes and see if the problem goes away. Next check the compression - and then the LZMA SDK
as described below?
Unsupported Compression?: 7-Zip: Unsupported method - use LZMA? I suppose this problem could still occur though that answer is a couple of years old.
Missing Runtime?: You might also want to do a dependency walker check on that setup.exe to see if it depends on something that is missing on the box (for example MSVCRT.dll - or another runtime library). Just download the tool. Easy to use. Or maybe first try to install commonly used C/C++ runtimes. Also, Dependency Walker is aging and shows garbage at times. There is the newer Dependencies - but it is not quite prime-time yet, but try it (click Releases tab). It has been updated to handle Windows API-sets and WinSxS (side-by-side assemblies). Note: several security software on virustotal.com detect Dependencies as a "risk tool, not a virus" (it is open source).
LZMA SDK: The 7zSD.sfx file would likely be from the LZMA SDK. And the command line you describe can be found in the main 7-Zip help file (not the SDK, but the one coming with the regular 7-zip installation). Section "-sfx (Create SFX archive) switch" : Command Line Version => Switches => -sfc (Create SFX Archive.
Alternatives
Visual Studio 2017: The newest, free version of Visual Studio: Visual Studio Community 2017 can create setup.exe files via its Microsoft Visual Studio 2017 Installer Projects (this extension must be installed after installing Visual Studio 2017).
WiX: The Open Source WiX toolkit can create setup.exe files with its Burn component. A WiX Burn ad-hoc sample- just to get the general idea - it has a learning curve. No GUI to help you, it is all XML-based. Use with or without Visual Studio.
Advanced Installer: I believe Advanced Installer can compile a setup.exe even in their free version. Despite a somewhat large download, I think this would work for you and be quick.
UPDATE on Advanced Installer: The free edition can only build MSI files, EXE bootstrappers can be built with the paid editions (any of them).
dotNetInstaller: There is also the dotNetInstaller Setup Bootstrapper - which I have never used. Here it is on github.com (source).
Inno or NSIS: These free non-MSI installers can easily create a setup.exe for you that has been
optimized for minimal dependencies. I haven't used them much, but they
are well-known. NSIS seems to create archive files compatible with Zip tools.
IExpress et al: There are security vulnerabilities that affect these self-extracting packages. Another reason I recommend a "real" deployment tool with dedicated resources to fix such things quickly, despite the niceness of having a setup.exe that can be opened directly in 7-zip.
File Extraction
On the topic of extracting files from setup.exe files of various types:
MSI: Extract MSI from EXE - all MSI files can be extracted, and setup.exe files created with WiX can also be extracted
NSIS & Inno: It looks like NSIS creates files compatible with 7-Zip (comprehensible compression), not so with Inno by the looks of it.
Some Links:
Wix and .NET Framework (prerequisites)
What is the difference between 7zip's 7z.sfx and 7zsd.sfx?
https://en.wikipedia.org/wiki/Self-extracting_archive#Overview : "For a decompression utility to correctly expand an archive of either
the self-extracting or standard variety, it must be able to operate on
both the file format and algorithm used. The exact executable code
placed at the beginning of a self-extracting archive may therefore
need to be varied depending on what options were used to create the
archive. The decompression routines will be different for a LZMA 7z
archive when compared with a LZMA2 7z archive, for example."
I am facing the following (fairly common) problem: I am running my program in Debug mode in VS2010 and/or VS2012, but at startup it crashes, saying:
The programme can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
Now I found a number of possible solutions, but none of them work for me:
Compile with /MTd instead of /MDd: actually this does solve the problem, but I am not allowed to: my program is part of a bigger program, and /MD[d] is mandatory.
Install the VS 2010 Redistributable package: This doesn't work because I have VS 2012 installed, so this installer tells me: "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
Finding, dragging and dropping a version of MSVCP100D.dll into the correct directory: I am not dropping unknown DLLs into places where they might interfere with other things.
Last resort: reinstalling VS2010/VS2012: possible, but as it would also mean reinstalling lots of other packages and plugins I need, I'd like to avoid this if it's not absolutely necessary.
Are there any other options left?
The Visual Studio REDIST packages never deploy the DEBUG versions of the CRT files. This is by design.
With VS 2012 or later, the easiest way to deploy the DEUBG versions of the CRT is to install the "Remote Debugging Tools" package on your test machines.
For VS 2012, the latest Remote Debugging Tools package is here
For VS 2013, the latest Remote Debugging Tools package is here.
Another option is to just use application local deployment of the DLL (i.e. copy it into your app directory). Again this is only for testing purposes. For actual deployment of your application, you are required to use the non-debug versions of the CRT.
If this error is happening on your development machine, however, then you have other problems because with VS 2012 installed, you should have the VS 2012 DEBUG CRT on that machine.
UPDATE:: Sorry, I would have expected the debug CRT DLLs to be included in the remote debugging tools package along with the remote debugger bits and the Direct3D 11 Debug Device. Alas, it's not. See Preparing a Test Machine To Run a Debug Executable. You have to either use the MSMs in Program Files (x86) directory in \Common Files\Merge Modules or copy the DLL-side-by-side from Program Files (x86) directory in \Microsoft Visual Studio <version>\VC\redist\Debug_NonRedist\. The VS Team probably assumed you would have already been doing that, but I'll suggest to them to roll it into the remote tools package.
I had a similar issue (the project made in VS 2012 but I was running VS2013) and resolved it by:
Open the project (or the solution ) in VS2013(or the newer one)
Open Project menu and select "Retarget the project" option (it was the first option but after applying it, this option vanished).
Rebuild your solution.
I am new to openCV and C++ and had the same problem using openCV 2.4.10 with Visual Studio Express 2013 on a Windows 7, 32-bit platform. If I made a simple program without using OpenCV, the program ran but when I used OpenCV I got the missing DLL error.
This post made things clear:
I guess the problem I had was not with my Visual Studio but my OpenCV. The OpenCV was compiled on a version of visual studio which required MSVCP110.dll. I could have tried another version of OpenCV or compiled OpenCV again using VS2013 but I was short of time. Instead, I found the dll file elsewhere and placed it in my system32 folder (not sure if that's recommended). This fixed the problem. However as #slater mentioned, I won't recommend downloading the dll from external website due to security issues.
This is a debug runtime DLL. If (and ONLY if!) you just want to run the debug build of your own application on a system without Visual Studio installed, then you can find the missing DLLs in
C:\Windows\System32 (for 64-bit builds)
C:\Windows\SysWOW64 (for 32-bit builds)
Just keep copying DLLs until your executable will run.
If this is NOT what you are trying to do, refer to https://stackoverflow.com/a/27386721/2279059, which is the CORRECT, but less practical answer.
I had the same problem, I found out that the cause is that I used dll compiled with VS2012 in a VS2013 project. JUST downloaded the missing dll and put it in my linker path and wala: the program worked. I downloaded it from http://www.dll-files.com/.
Particulars: My program was working in in release mode but not in the debug mode as it says the MSVCP110D.dll is missing. My code was an opencv image processing program. I put the missing dll in opencv linker path in the VS2013 project options.
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.
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
My program contains several dlls which depend on MSVCP100.dll and MSVCR100.dll, in Win7 my program runs without any problem, however in Win8 it failed to locate these two dlls. I notice that in Win8 there is no VCRedist installed by default, so apparently I need to install the VCRedist to enable my program.
The question is, how do I check if the VCRedist is installed?
Looks like we can do it by searching in registry [1] [2]. However, it seems there are many versions of VCRedist(VC2012,2010,2008,2005...), so I need to go through all these registry keys?
Since your DLLs depend on MSVCR100.dll, you'll want to find VCRedist for VC 2010.
The number after 'MSVCR' or 'MSVCP' is the internal version of Visual Studio x10 - http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Version_history lists the values for the various versions.
For Visual Studio 2010 you can detect if the runtime is already installed by checking the "Installed" value of HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x86 for 32-bit applications/DLLs and HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x64 for 64-bit applications/DLLs.
For Visual Studio 2010 and previous versions, http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx has a good explanation of methods for detecting if the runtime is installed.
With Visual Studio 2012 things have changed and the VCRedist key no longer exists. Instead you may look at the Installed value of the reg key (for 32-bit applications) Software\Microsoft\VisualStudio\11.0\VC\Runtimes\x86
If you just run installer of VCRedist (which you should ship with your program, anyway), it will do the job for you. Games "try" to install DirectX the same way.