I have a C++ Project in Visual Studio 2022 (Windows 11) that is put together using CMake. I understand that the difference here is, that my project is not a Solution but rather just folders with code and the CMake tells it how to compile it?
But my problem is, that it doesn't seem to find C's standard libraries and shows error "cannot open sourcefile".
Screenshot
The error is definitely not in the project, since it runs just fine on my laptop, just not on the PC I want it to run on.
How can I tell it where these libraries are? Where are they located even?
Any help would be greatly appreciated and I can share more files on request.
Things I have tried:
Going to properties and choose the correct Windows SDK Version - The properties are empty
Comparing every variable of the CMake Settings with the ones on my laptop where it works
completely reinstalling Visual Studio (yes I did that)
looking through lots of StackOverflow questions but none of them describe my problem
I recently came up with an issue. I had a project created on visual studio 2015, using allegro5 library which executed on Debug and Release mode correctly.
When I changed visual studio versions though and started using 2019 version (In the mean time I had to format my PC and re-installed only VS19) and loaded the project, the execution had a missing msvc110d.dll error shown up.
I tried to find a way in order for my project to be "upgraded" and instead of looking into the old version of msvc to try and look up the newer version, but couldn't find anything.
So is there a way for me to change some settings in order for my project to expect newer versions of msvc, or do I have to create a new project and copy paste all the configurations and files/assets inside that new project?
Thank you all
P.S I know that the error can be resolved If I get the .dll file inside that directory, but that is bad practice for sure. Also could you give me a tip on how to setup a project correctly in order to prevent those kind of issues in the future?
I think you need to find the VS2015 redistributable on Google and install it on your machine. That should solve it.
Windows dynamic library files are installed under c:\windows\system32 directory. A 32 bit dll file in a 64 bit windows can be found under c:\windows\syswow64. When your VC++ developed application searches for the dll it first checks in the application folder and then the system folder. If it is not found in these locations, a "missing dll file" error will be shown.
Normally, installing the right VC++ redistributable does the trick. But at times the mismatch persist as the sdk you're using is not in conformity with the system dll. You shouldn't replace the existing dll in the system directory manually with a downloaded( download only from www.microsoft.com) one as other installed software may also failed in the process.
In such worse case scenario, you can however directly copy the downloaded dll files in your application folder itself and distribute along your software so that it runs on a remote host too. Normally these compatible dll files, for both debug and release versions, are also available in your VC++ sdk directory which can be copied for a perfect match.
I've done a whole tutorial about making a 3D Rendering Engine in OpenGL with Java and lwjgl and the guy who made the tutorial also wrote the engine in C++
To increase my knowledge about programming I wanted to take a look at the C++ version too. Also I believe (and I might be totally wrong) that I'm actually able to do a lot more with C++ than with java. The main problem I have is that I cannot get the engine running despite the included instructions and I would really appreciate if someone can help me out.
this is the engine i want to setup: https://github.com/BennyQBD/3DEngineCpp
I want to use CodeBlocks for this project since it was recommended and unlike Visual Studio it is free.. I also already downloaded glew, assimp and sdl and I installed CMake which are needed for this to run. Now I have to put that together according to this instruction here:
###Windows/MinGW###
- Make sure CMake is both installed and added to the system PATH.
- Open a Terminal and run:
```Shell
# install dependencies
# Install GLEW in %PROGRAMFILES%/GLEW or SET %GLEW_ROOT_DIR% to where GLEW is on your machine (Example: D:\PATH_TO_GLEW)
# Install SDL2 in %PROGRAMFILES%/SDL2 or SET %SDL2_ROOT_DIR% to where SDL2 is on your machine (Example: D:\PATH_TO_SDL2)
# Install ASSIMP in %PROGRAMFILES%/ASSIMP or SET %ASSIMP_ROOT_DIR% to where ASSIMP is on your machine (Example: D:\PATH_TO_ASSIMP)
cd build
# REPLACE "Visual Studio 12" with your preferred build toolchain (Maybe you want "Codeblocks - MinGW Makefiles")
# BTW VS 10 is VS 2010, VS 11 is VS 2012 and VS 12 is VS 2013, BLAME MicroSoft for the naming! LOL!
cmake -G "Visual Studio 12" ../
# open the generated SLN file (or cbp file if using CodeBlocks) and build!
```
- Copy the DLLs in /lib/_bin/ to /build/Debug/ and /build/Release/
- In Visual Studio, set the Startup project to 3DEngineCpp
- Move the res folder into the build folder
- Run
Major problem is, since I've only done java coding in eclipse I'm a bit confused..
What does he mean by "Open a Terminal and run: '''Shell" ?? and how am I supposed to install glew, sdl2 and assimp? what's cd build? and why do I need CMake, it isn't really mentioned what it does..?
Maybe someone can elaborate (step by step if possible) what I need to do in order to get this running, thanks a lot!
No guarantees my steps will work flawlessly as external dependencies in C++ is still very painful to deal with for me, but I'll give you some leads and hope you make some progress. Also, I've never used Code::Blocks, so I'm not sure if Visual Studio projects are compatible with it. This is the only way I know how to do things on Windows.
First, you'll need to install CMake. CMake is a utility that generates project files so that the project can be easily compiled on certain platforms. It generates Visual Studio project files on Windows, which will allow you to open the project in Visual Studio, and compile them from there.
In order to build the project, you'll have to sort out its dependencies first.
GLEW:
Download GLEW's sources and extract everything. It comes with Visual Studio project files
Open up Visual Studio with Administrator permissions
Open up GLEW's project
Build everything
Run the install "project" to get Visual Studio to install GLEW
Assimp:
Download Assimp's source from GitHub
Extract the project root directory somewhere. The root directory is the directory where CMakeLists.txt is in
Open CMake's GUI utility
Click Browse Source, and select that directory
Select an output directory by clicking Browse Build
Click Configure, when that's done click Generate. This will generate a Visual Studio project file for you
Open project with Visual Studio, build everything. Run install like you did before to install Assimp
SDL2: SDL's sources come with Visual Studio project files, so you can repeat the steps for GLEW to install it.
Now you can finally start attempting to get the engine to work. No guarantees that it'll work, but I'd try the same thing I suggested for Assimp as they're both CMake projects. Once the project files are generated, you can open it up in Visual Studio. Except this time, you won't really be installing it. You can modify the sources and run it like you would any other C++ project.
Following the instructions here:
docs.opencv.org/doc/tutorials/introduction/windows_visual_studio_Opencv/windows_visual_studio_Opencv.html#windows-visual-studio-how-to
I setup an OpenCV project in VS 2015 Community and used the pre-built libraries. It works until I get this message:
"MSVCP120D.dll is missing from your computer"
From doing some searching I gathered this means that the pre-build libraries are only supposed to be used with an older version of VS so I figured I'd just compile them myself using this:
docs.opencv.org/doc/tutorials/introduction/windows_install/windows_install.html#windowssetpathandenviromentvariablehere
While it appears to compile properly and despite flagging "BUILD_SHARED_LIBS" I can't find any DLL files in the output - just a lot of VS solutions:
imgur.com/JdSc5CH
Would someone be able to give me some advice on how to generate the DLLs?
thanks!
I'm a beginner at this stuff. I've since learned a lot about Visual Studio, about CMake and about OpenCV. Got it all working now, took me a day or two.
It turns out you have to compile the openCV library from git repository in order to be compatible with Visual Studio (VS14) 2015. As of this date, no go on pre-compiled version supporting VS14.
I've organized what I've learned, placed it online here in case anybody else has the same frustrations. Its pretty detailed, too much content to post here.
VS2015 uses MSVCP140.dll, I think your error message is about a redistributable package of VS2013.
And try BUILD_SHARED_LIBS as on/off.
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.