I have some old code which is compiled using Visual Studio 2008.
This is launched by our developer environment setup to allow us to compile Curl. For some reason, when I've come to install it on a new dev machine, the Curl compilation doesn't find windows.h.
A bit of digging suggests the VCVars.bat file finds the following directory:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A
The last SDK version that looks like it's in a structure which includes windows.h is:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A
If I take a copy of VCVars.bat and modify it to manually set the WindowsSdkDir environment variable, I can get the compilation to work. This all feels rather hacky though.
Is there a correct way to fix this?
Edit - Wikipedia suggests the later directories are installed from Visual Studio 2013
Related
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.
In VS2017 location of Visual C++ Tools has new installation model
Now it is located somwhere like C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25203.
Or it can be for example C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017.
So full path depends on VS2017 edition and build number.
There is a macro $(VCInstallDir) which points to ..\VC** folder. But I need to know full path including part which depends on VS2017 **build number. I need this to find Visual C++ tools' include folder.
So can I determine this path without calling VS2017 Command Prompt (VCVARSALL.BAT) or PowerShell script etc.? Is thete some VS macro that I can simply put into VC++ Directory\Additional Directories property of my project?
Check out MSBuild variable $(VCToolsInstallDir), it should do the job for you. It is available in VS2017 C++ projects and its value is set to something like
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\
(depending on your tools version). Alternatively you can use $(VCInstallDir) and $(VCToolsVersion) to construct the path, but $(VCToolsInstallDir) should be more reliable.
P.S. Please note these variables only work in VS 2017 and are not available in previous versions of Visual Studio.
How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.
I'm trying to compile a visual studio C++ project and I can't get anywhere because of the compiler reporting "Cannot open include file: 'excpt.h': No such file or directory". The problem has been reported numerous times on the Internet but I can't find any help regarding my particular situation. The problem is not that the include path of the project are not correctly setup, the problem is that this include file (and probably a bunch of other files) are just missing from my computer. There is no such file on my hard drive. So I tried installing Windows SDK 7.1. The file is not inside the installed SDK (although it should be). I tried repairing the install, uninstall it, reinstall it... all numerous time. I also try to install, repair, uninstall, reinstall Visual Studio 2010 professional numerous time, with and without the Windows SDK installed. I even tried uninstalling the professional version to install the express VC++... nothing seems to work, no 'excpt.h' never get installed on my computer. I am clueless... someone has a hint of a solution? I'm on Windows 7.
As supplementary information, note that 'excpt.h' is included in by "windows.h". Also, the "excpt.h" file is normally installed with the Windows SDK under a path like "c:\program files (x86)\microsoft sdks\windows\v7.1\include\" and with Visual Studio under a path like "C:\Program Files\Microsoft Visual Studio 10.0\VC\include\".
EDIT: If it might help, I might add that the folder C:\Program Files\Microsoft Visual Studio 10.0\VC\include related my Visual Studio install has only two files... which is certainly not normal!!! However, I can't find any ways to get the installer to install all the .h files that should appear in this repertory.
See if you have it at C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\excpt.h Check to be sure that the system include-paths are correct in Visual Studio. If all else fails, uninstall everything, all SDK's, etc., and re-install Visual C++.
Third party search programs do a better job than the Windows one for finding things. Try Agent Ransack. It's free.
For those who have the same problem, here is the solution I found after about 10h of install/uninstall/cleaning cycles... I've uninstalled completely visual studio using this. After that, using the control panel, I've uninstalled the Windows SDK and everything that can be associated with it or with visual studio (e.g. .NET framework). Then, I've removed all the left overs by manually deleting the visual studio and the Windows SDK folders located in C:/Program files. Finally, I deleted all the entries related to the Windows SDK or to Visual Studio in the registry (they are located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft). Then, I reinstalled Visual Studio... and it was finally working correctly. I should add that I restarted and cleaned the registry using CCleaner after any install or uninstall step.
I had this problem with a project that had been updated to VS2017 from VS2015.
This was a header included via windows.h. I knew this header should have no problems as I had other projects created directly in VS2017 that used windows.h.
Another symptom was that the intellisense was highlighting includes of standard headers (e.g string, vector etc), although these were not generating compile errors.
The fix for me was similar to VS 2010 Cannot open source file “string”.
Initially, I retargeted the project, hoping this would help (right-click the project, select retarget projects), but this did not in itself cure the problem.
I then took a working project and copied the include directories from project properties->Configuration Properties->VC++ Directories and used these to replace the same property for my broken project. This fixed the problem.
Initially, the value for this property was
$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSDK_IncludePath);
The replacement value was
$(VC_IncludePath);$(WindowsSDK_IncludePath);
I had the same problem, and tried the answer given by OP, but it did not work. However, copying the contents of C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC (specifically bin, lib, and include) from a machine that did work to this machine worked.
It seems the Visual Studio 2012 installer is buggy when it comes to installing into a different drive letter than C:. I have installed the VS2012 into the D: drive and got the same error. I found that for some unknown reason the installer put some of the files into the correct location at:
D:\Program Files (x86)\Microsoft Visual Studio 11.0
but the remaining files were at
C:\Program Files (x86)\Microsoft Visual Studio 11.0
so I have moved the files from the C: into the D: location and it fixed the problem.
Some situation cause such problem. If you have uninstalled vs2010. you lost platform C++ binaries for .net framework 4 forever. You have to delete all of VS 2010 2012 2013, clean system up and its accompany components and reinstall them from scratch.
Or you can download this package. Include them in your project that may solve your problem properly.
one simeple way,just copy vc directory(C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC) from other computer
Fixing your Visual Studio installation is a good idea, but you don't necessarily need to re-install the same old version of VS. I uninstalled VS 2015, then modified my VS 2017 installation to add the VC++ v140 build tools, and now my project builds.
I tried to compile the source code of cryengine 3 and I always get the following error message.
Error 1 error : Required file "tracker.exe" is missing. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets 251 6 CryGame
For some reason I couldn't find any information on google.
Could it be possible that my Visual Studio installtion is somehow corrupt? I am still using the release candidate
A quote from MS website about tracker.exe:
Tracker.exe is required to correctly incrementally generate resources
in some circumstances, such as when building on a 64-bit OS using
32-bit MSBuild. This build requires Tracker.exe, but it could not be
found. The task is looking for Tracker.exe beneath the
InstallationFolder value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A.
Possible solutions:
Install the Microsoft Windows SDK v7.0A or later.
Manually set the above registry key to the correct location.
You short-circuit that lookup instead by setting the
ResGenTrackerSdkPath property to the 7.1 .NET 4.0 tools location. In
the build definition, under "MSbuild Arguments", you can add the
following:
/p:ResGenTrackerSdkPath=":\Program Files(x86)\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools
EDIT: your path may differ a little, but this still shows the general path to add
You can go to the directory "C:\Program Files (x86)\Microsoft SDKs\Windows".
Then, you search for the key "tracker.exe", if you can't find it, it might been deleted somehow.
The best way is:
Copy the folder "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools"
To your PC at the same directory.
If it didn't work, you can copy the folder into them[the following picture] every one.
picture: