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:
Related
I'm getting a common error on the issue that I'm having but nothing has worked:
1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.32.31326\include\yvals.h(12,10): fatal error C1083: Cannot open include file: 'crtdbg.h': No such file or directory
I've been told to download the C++ dev kit again, the Windows SDK again, Reset my PC after download and manually change the path inside the file that can't find it.
As it turns out the file exists (and the Windows SDK too, I assume), Visual studio is just looking for it in the wrong spot, So I figure this is a setup issue. It exists in this location C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt. You could say why not just manually link to it? I have but then another file can't be found, so I change that and then another one can't be found and so on. I'd appreciate the help as this is the reason I get scared to use Visual Studio and go back running to Code, thank you!
Does this issue also occur if I create an empty C++ project and build it? If it works fine, this issue is more relevant to your current project.
Please check the target platform version of your project. Right click the project name and select ‘Properties’—‘Configuration Properties’—‘General’— ‘Windows SDK Version’ like the following, and select the Windows 10 SDK to have a try.
You could also refer to the method in this issue.
(PS:You need to make sure that the SDK you install is consistent with the operating system, for example if you use Win 11 then you should install the Windows 11 SDK.)
I'm building a new TFS build server and decided to use the VS 2017 Build Tools instead of installing the full versions of VS. When I attempt to build our C++ projects, it throws the following error:
Error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found.
After many hours of research I'm no closer to resolving this issue. I tried adding the following registry settings but it did not help.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
I'm guessing Microsoft's installer is broken for this product. Is there a standard fix for this error or should I scrap my efforts and simply install the full versions?
In the project file, I found this entry:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
So, I guess this means that the variable VSTargetsPath is somehow pointing to the root of the D: drive but I haven't got a clue where that value is being set. Our current build server does not have an environment variable set named VSTargetsPath, but it does have the missing registry entries. It also has full versions of VS installed.
VS 2017 Build Tools failing with Error MSB4019: The imported project “D:\Microsoft.Cpp.Default.props” was not found
Try to pass VCTargetsPath explicitly as property to msbuild from your build configuration:
Edit the build definition for the build.
Click the process tab.
In the Advanced section, set the MSBuild Arguments to include the following property:
/p:VCTargetsPath="C:\Program Files (x86)\Microsoft Visual Studio\2017\xxx\Common7\IDE\VC\VCTargets\"
Save the build definition.
Note: You should change the value of VCTargetsPath to the location of the VCTargets folder.
Or pass VisualStudioVersion as property to msbuild:/p:VisualStudioVersion=15.0
If you are interesting in the value of $(VCTargetsPath), you can check following threads for some more details:
Can't find registry entries for Visual Studio 2017
Visual Studio Locator
Over the years Visual Studio could be discovered using registry keys,
but with recent changes to the deployment and extensibility models a
new method is needed to discover possibly more than once installed
instance. These changes facilitate a smaller, faster default install
complimented by on-demand install of other workloads and components.
vswhere is designed to be a redistributable, single-file executable
that can be used in build or deployment scripts to find where Visual
Studio - or other products in the Visual Studio family - is located.
For example, if you know the relative path to MSBuild, you can find
the root of the Visual Studio install and combine the paths to find
what you need.
You can emit different formats for information based on what your
scripts can consume, including plain text, JSON, and XML. Pull
requests may be accepted for other common formats as well.
vswhere is included with the installer as of Visual Studio 2017
version 15.2 and later, and can be found at the following location:
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.
I'm going to use the HelixToolkit.SharpDX with VS2017 in my Windows 10 workstation, when I attempt to build the solution, it will prompt the Assertion Failed error with "No fxc.exe found".
I have checked the installation option, Windows SDK has been included, nand I have downloaded and install again, and I can see the fxc.exe in "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64" & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86" folders, so it should be available for any windows version, but unfortunately, the same error reported.
However, I have also installed VS2017 in another Windows 7 machine, it works fine, and it has the fxc.exe in the same folder as my Windows 10 workstation, but it can be located by VS2017.
Is there any setting in VS2017 to locate the fxc.exe?
Or how can I fix this issue?
Copy fxc.exe in Bin\10.0.xxx\x86 to Bin\x86 to fix this issue. Because the HLSL compile tool hard coded the path.
One can find solution on helix toolkit github page.
Visual Studio 2017. Windows 10 SDK.
Missing fxc.exe issue with newest Windows 10 SDK:
Copy fxc.exe in C:\Program Files (x86)\Windows
Kits\10\Bin\10.0.xxx\x86 to C:\Program Files (x86)\Windows
Kits\10\bin\x86 to fix this issue. Because the HLSL compile tool hard
coded the path.
This seems to have been fixed in Visual Studio 2019 16.0.2, as of writing. Just have to make sure $(WindowsSDK_ExecutablePath) is pointing to the correct SDK directory and the build version that matches with the Targeted Platform in the Project Properties page.
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a3032567-d8e7-4b01-81b7-0612047a6299/why-do-we-need-to-copypaste-fxcexe-from-bin100xxxxx0x86-to-binx86-directory-in-the?forum=windowssdk
Second post answered:
The executables that the C++ build process uses from the Windows SDK directory are MIDL.exe, MT.exe and RC.exe. If you digitally sign your executables then you will find signtool.exe here too. So I am kind of surprised that it finds some critical build tools correctly but others it fails to find.
My suggestion would be:
1) Verify that you are having this problem with your project in Visual Studio 2019 16.0.2 (the latest version at the time of writing) or Visual Studio 2019 Preview (16.1 Preview 1 at the time of writing). This is to check that if this has been found to be a bug, then it could have been fixed.
2) Create a completely new project. Without touching the project's executable path, try to create a sample that shows this behaviour. It doesn't need to be a full sample, just complete enough to show that Visual Studio fails to find fxc.exe.
3) If doing all of this shows that Visual Studio fails to find fxc.exe, then through Visual Studio 2019, report it as a bug.
But I will mention that a naïve test on my end shows that Visual Studio 2019 can compile HLSL shaders without any issues using the 18362, 17763 and 17134 SDKs. These were tested because these are the versions that I have installed.
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
I've been following theForger's win32 API tutorial, and I decided to open the menu_one.rc file to see its contents from within VS2010, and I got this error:
I've double-checked both locations and neither of the files actually exist. The only copies of rcdll.dll I have are located at:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\rcdll.dll and
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\rcdll.dll
I've tried doing a repair install of the Windows SDK, but that didn't fix the problem. What should I do?
This thread mentions a registry issue:
I had been able to reproduce the issue with my pc with Windows 7 SP1 64 bit and VS2010 Sp1 installed.
What I had to is modify the following registry entries from
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows]
"CurrentVersion"="7.0"
"CurrentInstallFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0\\"
to
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows]
"CurrentVersion"="7.0.30319"
"CurrentInstallFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\"
And there were 2 keys under
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows]
which are
v7.0
v7.0A
I deleted v7.0 along with all its subkeys. And the problem is solved.
I was a little worried about changing the registry since I'm running on v8.0A, but I was able to fix the error by simply copying the rcdll.dll from previous version into the directory listed in the error message.
VonC's answer is helpful, but in my case it did not solve the problem. There was another registry key that needed to change.
To find that key, I searched regedit for v6.0A since that was the version in the path on my error dialog.
The dialog path was C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\rcdll.dll
Once the key containing v6.0A was found, I replaced the path with what it was on my machine:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I also updated the version strings to be v7.0A or 7.0.30319 depending on what the original value was. I found a few of version strings in sub-keys of my search result, so I applied the changes there as well.
On my machine, the key that Visual Studio was using was located in:
[HKEY_USERS\S-1-5-21-627493193-880714491-1605132347-6179\Software\Microsoft\Microsoft SDKs\Windows]