The curious case of error C2065: ‘IID_InterfaceName’: undeclared identifier

Recently, I stumbled across a peculiar error that I found nothing about on the web. Although I got rid of it, I didn’t figure out what the problem was. This post is merely the story of what happened.

I am working on a project that contains both C++ and C# projects. The C++ ones used to be built with /std:c++17 and we wanted to upgrade. So I switched to /std:c++latest and /std:c++20 for those containing C++/CLI code. Of course, this didn’t come for free, I had to fix a large amount of errors first, but in the end everything was building and working fine. Except that it didn’t.

The next day after committing the changes, we found out that the nightly built had failed. Looking in the logs, the following error appeared several times:

139>C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.36.32532\atlmfc\include\atlctl.h(4397,61): error C2065: 'IID_InterfaceName': undeclared identifier

This was odd and to check what was going on I opened the sources with Visual Studio and built the solution on the build machine and there was no error. But running the build scripts produced this error every time.

We were using Visual Studio 2022 17.6.x. So it happened that that day version 17.7 was released and we upgraded to that thinking it might be something in the build tools that might have been fixed, but of course, there was no change. The same error continued to occur.

Looking at the build scripts, I realized the actual build was done by running the following command:

devenv.exe "C:\path\mysolution.sln" /Out "C:\Build\Logs\mysolution.log" /Rebuild "Release"

So we weren’t using MSBuild but Visual Studio itself to run the build. This is unfortunate because there are only a few options you can pass to devenv.exe. For instance, you can’t specify the verbosity of the build. If you need more detailed logs, you first need to start Visual Studio, go to Options and change the MSBuild project build output verbosity.

It looked like that opening devenv.exe and running a rebuild from the UI worked fine, but passing the solution as argument to devenv.exe and running without any UI didn’t work well. Looking at the detailed log, I could see a cl.exe command that looked like this (a simplified form is shown here):

C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.36.32532\bin\HostX86\x86\CL.exe /c /I.\Include /Zi /nologo /W3 /WX- /diagnostics:column /O2 /Ob2 /Oy- /D HAVE_CPP_STDLIB /D NDEBUG /D WIN32 /D _WINDOWS /D _ATL_NO_UUIDOF /D _VC80_UPGRADE=0x0710 /D _MBCS /D _AFXDLL /GF /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++latest /Yu"stdafx.h" /Fd"..\..\Output\Release\vc143.pdb" /external:W3 /Gd /TP /analyze- /FC /errorReport:prompt /Zm200 /FS MyFile.cpp

That didn’t ring any bell though. But running the command by hand in a command prompt I could reproduce the error.

So the header where the error occurred was atlctl.h. It looked like we didn’t even need to include this one, so removing it immediately solved the build problems. But the mystery remains. I was not able to identify the cause for the different results in compiling the same sources with the same tools. If anyone has any knowledge of the cause of this I’d love to hear about it!