I am adding unit tests to an existing C++ Visual Studio projects, using the Google Test adapter.
It's all running fine on my computer with Visual Studio 2019, but when I try to run them on the build server I get the following error
error : This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.3\build\native\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.targets.
However, we're not using NuGet for package management. I tried installing it but complained about missing folders. This is not a .NET project, so I think that's a red herring.
I was able to install the Google Test adapter on my computer using the Visual Studio Installer, but it does not show up as a part of the VS Build Tools on the build server.
Running msbuild -t:restore does not help, it just reports "nothing to do."
I don't understand why the Google Test adapter isn't available for VS Build Tools, since it seems to be required in order to build the unit tests. Does anyone know why it doesn't work? What's the best practice for handling this?
Thanks!
The problem is that your c++ project has missed the content of googletest nuget package. So the solution is to restore the whole nuget package in your c++ project.
Update 1
First of all, take a brand new backed up project and restore it to when the problem started.
Besides, msbuild -t:restore command applies to projects with PackageReference nuget management format.
Since your c++ project used packages.config nuget management format, msbuild -t:restore will not work. See this official document.Instead, you should use nuget restore command.
This command works for your current project and running this command will restore the nuget packages and then you will never face the issue.
Before using it, you should download nuget.exe CLI and config its path into System Environment Variable PATH so that CMD can invoke nuget.
The steps about configing nuget.exe, you can refer to this link.
Steps
1) delete packages folder under the solution folder
2)Then, open build tool, run:
nuget restore xxx\xxx\xxx.sln(the full path of solution file containing the c++ project and the unit test project)
Then, you can build the project with the command. And I hope the error will disappear.
I recently updated visual studio 2015 and now, when i try to build any project it always fails and i get the error
Severity Code Description Project File Line Suppression State
Error MSB8036 The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the
project property pages or by right-clicking the solution and selecting
"Retarget solution". Proj D:\Program Files (x86)\visual studio
2017\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141\Toolset.targets 34
I retargeted the solution as it said, and the problem persisted, even though the retargetting was completed.I decided to install visual studio 2017 because of this, and, lo and behold, it did the exact same thing.I'm also using windows 7.
What is the problem and how can i fix it?
I faced this problem too. Re-ran the Visual Studio 2017 Installer, go to 'Individual Components' and select Windows 8.1 SDK. Go back to to the project > Right click and Re-target to match the SDK required as shown below:
I installed the 8.1 SDK's version:
https://developer.microsoft.com/en-us/windows/downloads/sdk-archive
It used 1GB (a little more) in the installation.
Update October, 9 (2020). There's a https error: the sdksetup link is https://go.microsoft.com/fwlink/p/?LinkId=323507
"Save link as" should help.
Another way (worked for 2015) is open "Install/remove programs" (Apps & features), find Visual Studio, select Modify. In opened window, press Modify, check
Languages -> Visual C++ -> Common tools for Visual C++
Windows and web development -> Tools for universal windows apps -> Tools (1.4.1)
and Windows 10 SDK ([version])
Windows and web development -> Tools for universal windows apps -> Windows 10 SDK ([version])
and install. Then right click on solution -> Re-target and it will compile
I had win10 SDK and I only had to do retarget and then I stopped getting this error. The idea was that the project needs to upgrade its target Windows SDK.
I realize this post is a few years old, but I just wanted to extend this to anyone still struggling through this issue.
The company I work for still uses VS2015 so in turn I still use VS2015. I recently started working on a RPC application using C++ and found the need to download the Win32 Templates. Like many others I was having this "SDK 8.1 was not found" issue. i took the following corrective actions with no luck.
I found the SDK through Micrsoft at the following link
https://developer.microsoft.com/en-us/windows/downloads/sdk-archive/ as referenced
above and downloaded it.
I located my VS2015 install in Apps & Features and ran the repair.
I completely uninstalled my VS2015 and reinstalled it.
I attempted to manually point my console app "Executable" and "Include" directories to the C:\Program Files (x86)\Microsoft SDKs\Windows Kits\8.1 and C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools.
None of the attempts above corrected the issue for me...
I then found this article on social MSDN https://social.msdn.microsoft.com/Forums/office/en-US/5287c51b-46d0-4a79-baad-ddde36af4885/visual-studio-cant-find-windows-81-sdk-when-trying-to-build-vs2015?forum=visualstudiogeneral
Finally what resolved the issue for me was:
Uninstalling and reinstalling VS2015.
Locating my installed "Windows Software Development Kit for Windows 8.1" and running the repair.
Checked my "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\8.1" to verify the "DesignTime" folder was in fact there.
Opened VS created a Win32 Console application and comiled with no errors or issues
I hope this saves anyone else from almost 3 full days of frustration and loss of productivity.
Grep the folder tree's *.vcxproj files. Replace <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion> with <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion> or whatever SDK version you get when you update one of the projects.
For me in the Project Properties Settings General->Target Platform -> Change Windows 8.1 to Windows 10 solved the issue
Install the required version of Windows SDK or change the SDK version
in the project property pages
or
by right-clicking the solution and selecting "Retarget solution"
If you do visual studio guide, you will resolve the problem.
I encountered this issue while trying to build an npm project. It was failing to install a node-sass package and this was the error it was printing. I solved it by setting my npm proxy correctly so that it could reach the npm repo
PROBLEM: I ONLY get this compile-time "Windows SDK version 8.1 not found" error ( and a few other very-hard-to-resolve-nuisance errors -- cannot list them all ) when I export a project from an old version of MS Visual Studio (VS) to the new MS VS (2017), using the new MS VS export/"One-way Upgrade" feature.
SOLUTION: I have since learned to not use this export/upgrade feature and instead just create the new project from scratch -- using all my old source files, of course. Only my project settings have to be rebuilt, to be clear.
This is a bit of a pain, and a shame the export/upgrade feature won't work properly like it used to, but this is is actually easier and faster in the long run. MUCH better than working through a list of spurious errors that really should not have arisen in the first place.
Hope this helps...
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 have an ASP.Net project that's using the ClearScript.V8 library which relies on the Visual Studio 2012 C++ Redistributable to work. I'm faced with the prospect of having to install this on 50+ machines and I'm curious if I can get TFS to do it for me.
I realize this straddles somewhere between Stack Overflow and Server Fault so I'm asking on both sites.
Assuming that the binaries for ClearScript.V8 is included in your project (either as files copied to the bin folder or as a NuGet package) you should be able to also include the necessary Visual C++ redistributables files as binary files in your project. They will then be stored in TFS.
If you prefer NuGet packages you can to set up a local NuGet repository within your organization and create a NuGet package with the necessary DLLs which you then can reference from your project. If NuGet package restore is configured for your solution the package will be downloaded before the solution is built. In VS2012 you will have to make some customizations for this to happen on a Team Foundation Build server.
If you are unsure which DLLs you need to include you can use a tool like Dependency Walker to discover which DLL's are required, or you can debug the application and see which DLLs are loaded in the modules window. Microsoft has some information which DLLs to redistribute.
If you are having problems with conflicting versions of a redistributable DLL getting loaded you can create a side-by-side manifest to ensure that the correct DLL version is loaded into your application. However, as your application is hosted within ASP.NET this is somewhat tricky because w3wp.exe is executed by IIS outside your direct control. You will have to create an activation context to configure the manifest used by your application.
If you need to have things installed on your server for a build I would recommend that you use Chocolatey.
chocolatey.org/
This is an implementation of NuGet in PowerShell to explicitly solve the issue that you face. You can create a powershell file that installs all of the bits that you need and easily include it as a pre build step in TFS 2013. You can use the PowerShell activity from the TFS Community Build Tools to call the PowerShell in TFS 2010 or 2012.
I’m writing a Sketchup ruby plugin that calls an external c++ application built using visual studios 2012 version 11.0.51106.01. Another machine that tried using the plugin gets an error about MSVCP110.dll being missing. They’ve tried installing the vcredist and it didn’t fix the problem. does anyone know how to fix this?
You will need to install the correct Redistributable Package from Microsoft. Please note that you cannot just take any of those, you need to pick the one that goes with your very specific version of Visual Studio. The link for example is for VS 2012 SP1. If you have another version, you need another vcredist package.
Answer of user nvoigt seems to be correct (+1 for that). As an alternative to install Redist Package you can deploy "manually" MSVCP110.dll with your application. Easiest way is to put the dll where your exe is. But as the other people say: you need the correct version of redist pack which fits your system configuration.
This article https://helpx.adobe.com/creative-cloud/kb/missing-msvcp110dll.html
pointed me in the right direction. The file wasn't, however, in the directory they said it would be. So I did a search of hard drive for vcredist_x64.exe. It was buried deep in a directory for VisualStudio 12. When I reinstalled it the dll error disappeared and photoshop is running again.
I think I created the problem when I installed a newer version of Visual Studio.