I created .exe using VS2013 and I added it directly to control panel by giving registry path. I built it for x64. It launches perfectly fine for Win8.1x64. But when I launches it on Win7x64 it gives MSVCP120.dll error. If I copy dll it works. But does the dll's are connected directly to .exe? If not how do I attach them?
Your error just means that the MSVC redistributable for VS2013 is missing from the Windows 7 computer. Windows 7 doesn't have this DLL by default.
However, please don't copy DLLs around willy-nilly. You need to make sure the redistributable is installed either as part of your installer or separately by the user. For example, you can have your installer detect the existence or not of the redistributable and alert the user to install it. You could include it with your installation package, which is allowed.
Note that there are 2 versions of the redistributable, for x86 and x64. You need to supply the right one(s) for your application. You can use this link to download the Visual C++ redistributable packages for Visual Studio 2013.
Even if you're using x64, you need to install also x86 version of MSVC redistributable.
I had this problem myself as well. I found that even after installing x64 version of MSVC redistributable, the msvcp120.dll file was missing in SysWOW64 directory. The issue was solved after installing also x86 version.
Related
I need to host an ASP.NET Core 2.0 app in IIS on Windows Server 2008 R2 SP1. I'm following the Docs guide on how to Host ASP.NET Core on Windows with IIS.
After installation, I still can't run dotnet.exe. It calls for a DLL named api-ms-win-crt-runtime-l1-1-0.dll.
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
However, there are lots of instances of this file on the machine, in the following folders:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.3
C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\2.0.3
C:\Windows\winsxs\amd64_microsoft-windows-u..rsalcrt-apifwd-win7_31bf3856ad364e35_6.1.7601.18972_none_a9a51144251fb166
C:\Windows\winsxs\amd64_microsoft-windows-u..rsalcrt-apifwd-win7_31bf3856ad364e35_6.1.7601.23175_none_aa31870f3e3ad077
C:\Windows\winsxs\amd64_microsoft-windows-u..rsalcrt-apifwd-win7_31bf3856ad364e35_6.1.7601.23656_none_aa4830af3e29a3af
C:\Windows\winsxs\x86_microsoft-windows-u..rsalcrt-apifwd-win7_31bf3856ad364e35_6.1.7601.18972_none_4d8675c06cc24030
C:\Windows\winsxs\x86_microsoft-windows-u..rsalcrt-apifwd-win7_31bf3856ad364e35_6.1.7601.23175_none_4e12eb8b85dd5f41
C:\Windows\winsxs\x86_microsoft-windows-u..rsalcrt-apifwd-win7_31bf3856ad364e35_6.1.7601.23656_none_4e29952b85cc3279
The instruction says:
Install the .NET Core Windows Server Hosting bundle on the hosting system. [...] If the system doesn't have an Internet connection, obtain and install the Microsoft Visual C++ 2015 Redistributable before installing the .NET Core Windows Server Hosting bundle.
I have installed/repaired both of these packages multiple times but get the same error.
It's probably not that the DLL is missing, but rather one of the DLL's dependencies is missing.
Make sure you're installing the Update 3 version of the Visual C++ 2015 Redistributable.
One of the requirements of the Visual C++ 2015 Redistributable is KB2999226. Make sure this is installed as well.
If it's already installed, post the installation log from the Visual C++ 2015 Redistributable installer package.
on windows server 2012 R2
I had same issue. Windows update + installing windows specific update solved it.
see: https://github.com/dotnet/core-setup/issues/4388.
I installed this update:
https://support.microsoft.com/en-us/help/3118401/update-for-universal-c-runtime-in-windows
TL;DR: Install these Windows updates in this order:
KB2919442
KB2919355
KB2999226
After installing the above 3 Windows update in the correct order, the error about the missing dll should stop.
I ran into basically this same problem when attempting to deploy a .NET Core 2.1 application to a Windows 2012 R2 machine. The root cause seems to have been due to a corrupt installation of the Microsoft Visual C++ Redistributable.
From Microsoft's documentation:
Visual C++ Redistributable Packages install runtime components of
Visual C++ Libraries on a computer that does not have Visual C++
installed. The libraries are required to run applications that are
developed by using the corresponding version of Visual C++.
After some troubleshooting and research, I fixed the issue by manually installing these 3 Windows updates in this order:
KB2919442
KB2919355 (requires a reboot)
KB2999226
The order of installation of these Windows updates is important! KB2999226 depends on KB2919355, and KB2919355 depends on KB2919442.
After installing those Windows updates, dotnet.exe and the application began to run correctly.
Have to ask this question once again here as none of the replies I found solve the issue.
So the goal is to set up the debugger for Qt Creator on Windows 8.1 x64. Visual Studio 2015 Update 3 (Community) and Qt 5.7 32-bit are installed on the system. As far as I understand I need Debugging Tools For Windows, which are a part of the Windows SDK. Visual Studio seems to install Windows SDK, but it doesn't have debugging tools. If I look into "C:\Program Files (x86)\Windows Kits\10\Debuggers" I see only one folder there, which is "x64" (and I suppose there must have been "x86" for 32-bit Qt). That folder contains three .dll files and no cdb.exe.
I tried to install Windows Debugging Tools manually as a part of Windows SDK, downloaded from here, but when I run the installer it gives me the error:
I guess that's because VS already has Windows SDK. Should I uninstall some component from Visual Studio? But I really don't want to break it.
Any help is appreciated
This error is taking toll of my training schedule.
Everytime I create any C++ application in my VS2010, It runs fine on my machine but if I run it on different machine, It starts with this error.
Error goes if I copy msvcp100.dll in System Folder then it shouts for some other DLL. It requires some 5-6 different DLLs.
Most irritating part is even if I write a simple Console based Addition program, It gives this error.
(I should not but)I would have agree if I design some fancy forms and all... But for simple Addition program????
Am I missing out somethings in Settings? or VS2010 to blame??
Somewhat related question: this But this problem seems different
By default, MSVC projects are set to link against the dynamic run time library which generates a dependency on the visual C++ run time redistributable. As you have already found out, this dependency is not guaranteed so your install utility has to install the visual c++ run time first.
You can avoid this by changing your project settings. Load the project properties and go to: "Configuration Properties"/"C/C++"/"Code Generation"
In the item labelled "Runtime Library", select "Multi Threaded (/MT)"
for the release version"Multi Threaded Debug (/MTd)" for the debug version.
You have to be careful while doing this that all the other libraries that your application links are also compiled against the static run time.
You need to have Visual C++ Libraries installed if you want to run your app.
Using the compiler options to change the runtime library worked for me ("Configuration Properties"/"C/C++"/"Code Generation". In the item labelled "Runtime Library", select "Multi Threaded (/MT)" for the release version and "Multi Threaded Debug (/MTd)" for the debug version). I did have to do both the debug and the release to get the release to work. Don't know why (it is possible that I did not do it correct the first time).
Note: I was using VC2010 Express version on Windows 7 to compile. I tested on an old XP machine.
Another note: MS information at http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.100).aspx
If you have installed a new copy of Windows on your computer or have reinstalled one then you will come across an error called "The program can’t start because MSVCP100.dll is missing from your computer. Try reinstalling the program to fix the problem." on your computer.
The basic reason behind this error is that the Visual C++ doesn’t get installed when you reinstall or install a fresh copy of Windows operating system. In order to check Visual C++ is installed on your PC or not, open Control Panel → All Programs and Features and then search for Visual C++ in the software list. If you don’t find the software installed there then you have to install it.
I would suggest, first of all, install the Visual C++ 2010 package and check if it has solved msvcp100.dll missing error or not. If the issue is not resolved by the Microsoft Visual C++ 2010 then install 2013 or 2015 versions of Microsoft Visual C++. Here is the list of download links of Microsoft Visual C++ for both x86 and x64 architectures:
Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
Visual C++ Redistributable Packages for Visual Studio 2013
Visual C++ Redistributable for Visual Studio 2015
→ The latest supported Visual C++ downloads
I hope, now you are able to fix “The program can’t start because MSVCP100.dll is missing error on your computer. To know more details, you can follow this guide.
Thanks
Visual C++ 2005 I build on my system use CRT DLLs version 8.0.50727.4053. I believe it is the latest one and was automatically updated by Windows.
On user systems, this version of the DLL is not found. I have used vcredist_x86.exe in the past as a part of our installer to install runtime DLLs. It used to work.
My problem is that even the latest version of vcredist_x86.exe (
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)) doesn't install this version of the DLL.
So which vcredist_x86.exe file do I need then ?
P.S. Would forcing my app to link to a specific version of the CRT solve the problem ? Is it a prefered method at all ?
Thanks,
Paul
UPDATE: There are other people who observe that vcredist_x86.exe (
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)) doesn't install 8.0.50727.4053.
UPDATE2: At least one person suggests forcing using the previous version of CRT (http://tedwvc.wordpress.com/). This would however add a significant complexity to our projects.
Following the advice of JesperE, I found that there exists "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update" which provides these distributables.
I think there's an important distinction for VS standard/professional users and VS Express users. For VC++ Standard, c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86\ contains the 8.0.50727.4053 redistributable (after the security update is installed). There is no need to separately install an SDK, so (for instance), I don't even have a C:\Program Files\Microsoft SDKs\ directory on the machine with VC++ Standard installed.
When using VS 2005 Express, follow mikets' answer, and get the ATL security update version. I confirmed these fix the problem in my case.
Ok. I found the solution in an MS Forum:
If you installed the security update,
the 9.0.30729.4148 version of vcredist
should be in your Windows SDK folder,
typically C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Bootstrapper\Packages\vcredist_x86
and C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Bootstrapper\Packages\vcredist_x64.
Original thread
Microsoft release an update (google for KB971090) containing a security fix for the VC runtime. There is a corresponding update to the vcredist_x86.exe, but I don't have a link. If you have KB971090 installed, I think you should have an updated vcredist_x86.exe somewhere on your machine.
In practise (IIRC), it means that binaries built on machines which has KB971090 installed can only run on machines which have the corresponding updated VC runtimes, i.e. you need to ship and install the new vcredist_x86.exe on client machines.
I hope this could be a useful information:
The file you're looking for (2.0.50727.4053) has a size of 2.705.744 bytes (2.707.456 bytes on disk).
My understanding is that Microsoft hasn't released a vcredist_x86.exe for this version. They did, however, release Merge Modules with this version, so you should download them and include them in your installer. Now where do you get these is also a good question, but I somehow magically got them, probably through InstallShield update.
On my machine I found the 8.0.50727.4053 redistributable in \Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
The one in \Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\vcredist_x86 was for VS2008.
-Greg
Note:
Installing the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update" mentioned by mikets above also may resolve the following problem:
Error 0xc0150004 upon starting devenv.exe (Visual Studio 2005) or reader_sl.exe (Autostart of Acrobat Reader).
Reason it fixes a corrupt installation of the above Assemblies. (Probably corrupted with an Windows update/service pack installation).
It looks like you can install a msm file directrly with the msiexec
see:
http://forums.winamp.com/showthread.php?s=&threadid=99668&highlight=msm
I have a Windows 7 machine with Visual Studio 2005 SP1 installed. Using this, I build an application which loads a DLL at runtime compiled with VS2005 SP1 but on Windows XP. This fails, with the following error:
"...\foo.dll": The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
The DLL loaded is compiled against the debug CRT. The answer to this question hints that vcredist_x86.exe only contains release-versions of the CRT. I'm not sure if that is relevant in this case, since both my machine and the machine on which the DLL was compiled on both have the full VS2005 SP1 installed.
Should I attempt to rebuild the DLL on Windows 7 (I'd prefer not to), and will that cause the DLL to become unusable on the Windows XP machine?
Problem solved. The problem was that the Windows 7 machine did not have the KB971090 update which was installed on the Windows XP machine which built the DLLs. I had to explicitly tell Windows Update that I wanted to receive non-Windows updates in order to be able to install the update.