I'm trying to configure a debugger for Qt Creator. However, I can't find cdb.exe. From internet, I found out that it is supposed to be located in C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\cdb.exe. Yet, I don't have directory C:\Program Files (x86)\Windows Kits\8.0\Debuggers. I do have a directory called C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64 but it only contains files dbghelp.dll, srcsrv.dll and symsrv.dll.
cdb.exe and the gui equivalent windbg.exe are part of the debugging tools for windows and have to be downloaded as part of the windows SDK, in the past it has been part of the DDK also.
You can get it here: https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx
If you're just interested in the tools there is a link for the standalone debugging tools (as part of windows 8.1 SDK) here: https://www.microsoft.com/click/services/Redirect2.ashx?CR_EAC=300135395
dbghelp.dll, srcsrv.dll and symsrv.dll are shipped as part of Windows and has been since Windows 2000 (I think this is certainly true of dbghelp.dll).
Related
I have a project that started as a Visual Studio 2005 project, and is now a Visual Studio 2019 project. It is built using the 142 Platform Toolset on Windows 10, but for deployment on Windows 8.1 and later. So it selects the Windows 8.1 SDK, and sets WINVER, _WIN32_WINNT and _WIN32_WINDOWS all to 0x0603.
It's an MFC project, so stdafx.h is virtually everywhere. That includes afxwin.h, which in turn includes afx.h and that includes new.h. It all builds fine on my desktop development machine with version 16.4.3 of Visual Studio 2019 Community.
I have just tried building the project on a laptop just after upgrading to "the latest" Visual Studio version (16.6.2). It fails to build because it cannot find new.h. As far as I can tell, new.h should be part of the SDK. But new.h is not in the Windows 8.1 SDK (or at least: not mine).
But what really confuses me is that when I track down new.h in my successful build, also configured to use the Windows 8.1 SDK, it finds new.h in the Windows 10 SDK.
I'm not clear if I have (a) a bad project (b) 1 or more bad Visual Studio installations (c) 1 or more bad SDK installations. Where should I expect to find new.h under such circumstances, and does that shine any light on which of a, b or c I'm experiencing?
Case (d): you are missing the Windows SDK 8.1 installation on the laptop. That needs to be done separately from the VS install. From the Visual Studio 2019 v16.0 Release Notes - Deprecations:
The Windows 8.1 SDK is no longer available in the Visual Studio installer. Please upgrade your C++ projects to the latest Windows 10 SDK. If you have a hard dependency on 8.1, you can download it from the Windows SDK archive.
[ EDIT ] Targeting the Windows SDK 8.1 does not remove all references to the Windows 10 SDK, which is still required and used. For example, the include path for a C++ MFC project using the v142 toolset and the v8.1 SDK is set by default to the following on my machine.
C:\Program Files (x86)\Microsoft Visual Studio\2019\VC\Tools\MSVC\14.25.28610\include
C:\Program Files (x86)\Microsoft Visual Studio\2019\VC\Tools\MSVC\14.25.28610\atlmfc\include
C:\Program Files (x86)\Microsoft Visual Studio\2019\VC\Auxiliary\VS\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
C:\Program Files (x86)\Microsoft Visual Studio\2019\VC\Auxiliary\VS\UnitTest\include
C:\Program Files (x86)\Windows Kits\8.1\Include\um
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Include\um
I am trying to evaluate a software SDK for displaying PDF files. It comes with a few sample projects, but I am having problems building the C++ projects. I am pretty sure this is a problem with my local environment, but I have no idea how to fix it:
The projects come as a Visual Studio solution, to be used in Visual Studio 2017. Upon first opening it I was told to install missing features (VS17 was a plain install with no workloads before):
After installing that, and twiddling with platform toolset and the general platform target settings, I could finally build the C++ library part that creates a .dll file to be used by the other 2 C++ projects. (I could also confirm that this works fine, as the also included C# project used the library perfectly fine.)
But for the 2 remaining C++ projects I get this error on build:
The package System.Net.Http with version 4.1.1 could not be found in C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\. Run a NuGet package restore to download the package.
FunctionDemo
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets
377
Unfortunately I have no idea what "Use NuGet Package Restore to download them." means in that context - both the solution and all the projects have nothing listed when using Manage NuGet Packages... in Visual Studio. So I don't even know where this dependency comes from. (Are those part of the general SDKs I have installed maybe?)
Double clicking the error message opens C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets with this:
<ResolveNuGetPackageAssets Condition="Exists('$(FrameworkInjectionLockFile)')"
NuGetPackagesDirectory="$(FrameworkInjectionPackagesDirectory)"
RuntimeIdentifier="$(NuGetRuntimeIdentifier)"
TargetMonikers="$(NuGetTargetMonikerToInject)"
ProjectLockFile="$(FrameworkInjectionLockFile)">
But I guess this is pretty standard. Does this tell me something where the error comes from?
On the filesystem C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\System.Net.Http\4.1.1 indeed does not exist. Any tries to fill it manually (download the nuget package manually to a project, and copying the results here, using any solutions or commands to run I can find online) failed.
If found out that C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\ is the package source Microsoft Visual Studio Offline Packages which I can view via Options -> NuGet Package Manager -> Package Sources in Visual Studio 2017, but disabling it there didn't change anything about the error message.
Am I looking in the wrong place?
Is this really my local problem or a project problem?
How can I fix this problem?
I "fixed" this by getting the C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\System.Net.Http\4.1.1 folder from another developer. Then the error message switched to other packages, so in the end he sent me his full C:\Program Files (x86)\Microsoft SDKs\NuGetPackages and I copied folders over until it finally built.
Still not idea what caused this, must have been a missing payload or SDK that Visual Studio thinks was installed but really wasn't :/
Keeping the question unanswered though in the hopes that someone comes along that know the real fix.
This happened to me after upgrading from Visual Studio 2017 to 2019. While not the same file, my error was:
error APPX0702: Payload file 'C:\Program Files (x86)\Microsoft
SDKs\NuGetPackages\System.Private.ServiceModel\4.1.3\runtimes\win7\lib\netcore50\System.Private.ServiceModel.dll'
does not exist.
For whatever reason, after upgrading, both VS 2017 and VS 2019 were looking for this in C:\Program Files (x86)\Microsoft SDKs\NuGetPackages..., but I found it actually existed in the similarly named folder C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages... instead. I assume during the installation of VS 2019 this directory was created?
I manually copied the files over to where it was looking and then the build finally worked. The underlying issue isn't fixed, but maybe somebody smarter than me can explain why this happened in the first place.
For me disabling C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\ didn't work either. But then I had deleted it from Nuget.Config and it had finally solved the problem.
I have created a c++ app using visual studio 2015. My distribution package requires files msvcp140.dll and vcruntime140.dll in order for my app to run correctly on another pc. According to https://www.visualstudio.com/license-terms/distributable-code-microsoft-visual-studio-2015-rc-microsoft-visual-studio-2015-sdk-rc-includes-utilities-buildserver-files/:
Visual C++ Runtime Files Subject to the License Terms for the
software, you may copy and distribute with your program any of the
files within the followng folder and its subfolders except as noted
below. You may not modify these files. C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\redist
Since both of the above files reside in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist I can distribute these two files with my executable.
However I also need file msvcr120.dll due to a precompiled third party library that I also use. This file resides in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools.
I know that there is an option by using specific inno setup file to check which vc++ redistributables are needed and to installed the correct ones. However for the time being I just need to include the relevant dll in my executable setup package.
So my question is whether I'm allowed to distribute msvcr120.dll with my package as well?
If you have VS 2013 and you can find the msvcr120.dll file under C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\arm\Microsoft.VC120.CRT, for the detail information, please check this: Determining Which DLLs to Redistribute
If you do not install the VS 2013, their DLLS are also available as stand-alone redistributable packages from the Microsoft Download Center.
Refer to Distributable Code for Microsoft Visual Studio 2013 and Microsoft Visual Studio 2013 SDK (Includes Utilities & BuildServer Files) and you should be able to distribute the msvcr120.dll file from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\arm\Microsoft.VC120.CRT.
Up to Visual Studio 2013 all you needed was msvcr[version].dll and msvcp[version].dll.
Now they changed the DLLs with 2015.
What do I need to include in order to avoid a redist installer?
EDIT:
It seems to be impossible now:
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
"App-local deployment of the Universal CRT is not supported."
UPDATE:
The content of the link above was updated on 11 Sep 2015. Now it's possible to make app-local deployment.
This worked for me (x86 app).
Shipping all dlls from these locations with your app:
C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT
Myself, I needed an additional file to make this happen. Here are the directories, with one in a more generic format:
Copy all the files from "C:\Program Files\Windows Kits\10\Redist\ucrt\DLLs\x86" or "C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86" (or copy them from the x64 directory if it's a 64-bit app).
Copy msvcp140.dll and vcruntime140.dll from:
<Visual Studio 2015 Install Directory>\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT (or copy them from the x64 directory if it's a 64-bit app).
If you're using Qt, copy these files into the directory made by windeployqt.
In general, I found that you can just do step #1, and attempt to run your app. It will tell you the first of the files it is missing, and once you have put it in your app's directory, it will tell you the next one you need. In my case, it was two. Copying similar files from my <Windows>\System32 folder, e.g., was not successful. I have found using Dependency Walker and trying to satisfy the dependencies it indicates to be unsuccessful.
This allows you to make a portable app that will run on M$ OS's as old as XP; or install for users without vcredist_x86 or vcredist_x64, who don't have admin privileges.
BTW: Step #1 is pretty official. Here it is at the MSDN blog: Introducing the Universal CRT They say to copy them all for an app to run on all M$ OS's.
In general, you can use dependency walker to find the list of dependent dlls.
Regarding the visual studio runtime dlls, what you are mostly concerned about are the dlls with Visual studio specific versions in them.
As mentioned at point 6) of this article now it's possible to make local deployment of the Universal CRT. To do that you should install Windows 10 SDK and copy all the binaries from C:\Program Files (x86)\Windows Kits\10\Redist\ucrt.
I have a fairly simple C++ project in Visual C++ 2010 Express on Windows 7. I have no problems compiling in Debug mode for Win32, but when I switch to Release mode for Win32 I get the following compiler error:
LINK : fatal error LNK1296: unable to load msobj100.dll
I know this question has been asked here, but I couldn't get a fix from that solution. I did a search for that file, and it is only located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. Within SysWOW64 and Win32, there are files called 'msobjs.dll', but that's it. Any ideas?
Try to install the Windows SDK to your computer. These Files Should be distributed.Along with it.
See here.
Copy the missing dll file from
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
to
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin.
VC\Bin is the runtime path.
This problem also bothered me for a long time, and I had to run Release mode in another machine...
and I find the solution just now.