invalid preprocessor command 'include_next'

[Cameron]

Hopefully this is the right place to seek help. I recently Installed oneAPI 2025.0.0 and am getting this error on a build that contains several C/C++  and Fortran projects in Visual Studio 2022:

error C1021: invalid preprocessor command 'include_next'

Visual Studio dumps me in float.h at "C:\Program Files (x86)\Intel\oneAPI\compiler\latest\opt\compiler\include\float.h" at the very bottom at line 450:

The files in question are in a C based project that is set to use MSVC, not Intel C/C++ compiler. Have I missed something obvious?

edit: When I do a file comparison of float.h from 2024.2/opt/compiler/include, the only difference I see is the #else clause for #include_next. I don't want to say this is a bug since I am not sure on the intention of this change.

[Alex_Y_Intel]

 I've escalated your question to our internal team for further investigation. 

[Cameron · Accepted solution]

Posting the fix in case someone searches for this exact error since this post seems to come up now. I hate when I find the exact forum post that says "I fixed it" without saying how!

In our build environment, we use a Directory.Build.targets file that modifies what Visual Studio uses for the IncludePath and LibraryPath variables. At one point we needed to have a programmatic way to switch the version of the Fortran compiler used to build the product. Visual Studio will recursively try to find this file (similar with .props) on launch and then load the instructions within.

My .targets file specifically set IncludePath to insert oneAPI paths before the content of what already existed in IncludePath. This causes Visual Studio to load float.h from the Intel include files, not from the Windows SDK if using Visual C++ / MSVC. The simple fix for me was to just append oneAPI paths after IncludePath like so:

$(IncludePath);C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\opt\compiler\include; ... <other paths>

If there is a better way to set these paths, I would appreciate the feedback. Our automated builds run devenv from headless instances (like cmd.exe). Most of this behavior stems directly from our need to use varying versions of the older IVF compiler for different products we supported.