I have a need to build a project from command line using msbuild. This has been working for years now, however after installing vs2022 it no longer works. I was previously using vs2019 msbuild command line with no problems. I have tried every combination of vs/toolset/winsdk I can think of but nothing works. If I compile from within vs there is zero issue.
But from command line I get (no matter the vs, toolset, winsdk version):
MSBuild version 17.9.5+33de0b227 for .NET Framework
Build started 15.02.2024 11:31:29 AM.
Project "C:\work_local\workspace\cpp\vs_issue\platform_tools_test.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "x64\Debug\".
Creating directory "x64\Debug\platform.71e888c7.tlog\".
InitializeBuildStatus:
Creating "x64\Debug\platform.71e888c7.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
Touching "x64\Debug\platform.71e888c7.tlog\unsuccessfulbuild".
ClCompile:
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\CL.exe /c /ZI /JMC /nologo /W3 /WX- /diagno
stics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /permissive- /Zc:wchar_t /Zc:forScope /
Zc:inline /Fo"x64\Debug\\" /Fd"x64\Debug\vc142.pdb" /external:W3 /Gd /TP /FC /errorReport:queue platform_tools_test.cpp
platform_tools_test.cpp
Link:
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\work_l
ocal\workspace\cpp\vs_issue\x64\Debug\platform_tools_test.exe" /INCREMENTAL /ILK:"x64\Debug\platform_tools_test.ilk" /NOLOGO kernel32.lib user32
.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC
:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:\work_local\workspace\cpp\vs_issue\x64\Debug\platform_tools_test.pdb" /SUBS
YSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\work_local\workspace\cpp\vs_issue\x64\Debug\platform_tools_test.lib" /MACHINE:X64 x64\
Debug\platform_tools_test.obj
LINK : fatal error LNK1158: cannot run 'rc.exe' [C:\work_local\workspace\cpp\vs_issue\platform_tools_test.vcxproj]
Done Building Project "C:\work_local\workspace\cpp\vs_issue\platform_tools_test.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\work_local\workspace\cpp\vs_issue\platform_tools_test.vcxproj" (default target) (1) ->
(Link target) ->
LINK : fatal error LNK1158: cannot run 'rc.exe' [C:\work_local\workspace\cpp\vs_issue\platform_tools_test.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:02.10
I have tried all the hacks of copying the rc.exe + rcdll.dll from the winsdk folder to the same folder as the Link.exe. The only thing this changes is that it then has the full path of rc.exe in the LNK1158 message.
In an attempt of desperation I also tried to use CMake with a very basic setup and it cannot find the compiler.
C:\work_local\workspace\cpp\vs_issue\build>cmake -G "Visual Studio 17 2022" -T host=x64 -A x64 ..
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:5 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
I've completely run out of ideas (short of setting up a VM with a clean windows environment and trying to reproduce my original setup).
I've tried uninstalling all VS versions, repairing the install. Any advice would be appreciated.
I've tried multiple versions of the windows sdk. Under all conditions rc.exe is in the path and accessible (after either using the VS developer console or running the vcvarsall.bat script) (ignore my attempt at running rce... fingers are faster than my brain)
The link and subsequent rc calls are as follows:
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\work_local\workspace\cpp\vs_issue\x64\Debug\platform_tools_test.exe" /INCREMENTAL /ILK:"x64\Debug\platform_tools_test.ilk" /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:\work_local\workspace\cpp\vs_issue\x64\Debug\platform_tools_test.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\work_local\workspace\cpp\vs_issue\x64\Debug\platform_tools_test.lib" /MACHINE:X64 x64\Debug\platform_tools_test.obj
C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\rc.exe /nologo /x /fo "C:\Users\PC\AppData\Local\Temp\lnk{EC0E3243-FF9A-4248-B473-A81E49E339C9}.tmp" "C:\Users\PC\AppData\Local\Temp\lnk{887BFFEF-FF37-4E78-8CB2-3AEE0C2DB4DF}.tmp"
Ok, I've resolved this issue. It is my organizations aggressive virus scanner.
One thing that clued me in (thank you @EdDore) was watching the procmon dumps while building. As soon as the rc.exe started the virus scanner process all of a sudden went crazy.
After some searching I came across this post: https://stackoverflow.com/a/65306958/4375845
The virus scanner really does not like the tracker app. So it basically kills it and drops all file that were handled by it.
By setting /p:TrackFileAccess=false
to the msbuild command (or setting set(CMAKE_VS_GLOBALS "TrackFileAccess=false")
for cmake processes). This appears to resolve the issue.
Of course you then lose incremental building. For my case, I don't care.
I imagine this does not come up when VS builds because the VS process is whitelisted (my guess, but dealing with corporate infrastructure is a nightmare).