Use `/Fe<file>` (single arg) syntax when generating `tasks.json` to support older versions of `cl.exe`

[toninlg]

Bug type: Language Service

Describe the bug

• OS and Version: Windows 10 20H2
• VS Code Version: 1.62.2
• C/C++ Extension Version: 1.7.1
• I installed Windows SDK 7.1 on Windows 10. I launch the developer command prompt, typing cl gives "Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86" and start code from the prompt. Whatever the project is single or multi projects, cl.exe is not detected.
• If I set the compilerpath manually in c_cpp_properties.json, the includepath is not set. If I manually set the includepath, the build failed in terminal:

  
  Starting build...
  cl.exe /Zi /EHsc /nologo /Fe: C:\Home\Public\test\main.exe C:\Home\Public\test\main.c
  cl : Command line warning D9024 : 
  unrecognized source file type 'C:\Home\Public\test\main.exe', object file assumed

main.c

LINK : fatal error LNK1181: cannot open input file 'C:\Home\Public\test\main.exe'

Build finished successfully.

**Expected behavior**
Correct detection of cl.exe and paths. Successful build and coherent output message, why is the build finished successfully?

- Configurations in `c_cpp_properties.json` after manual settings of compilerpath and includepath

{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**", "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "cStandard": "c89", "cppStandard": "c++98", "intelliSenseMode": "windows-msvc-x86", "compilerPath": "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe" } ], "version": 4 }

- generated tasks.json

{ "type": "cppbuild", "label": "C/C++: cl.exe build active file", "command": "cl.exe", "args": [ "/Zi", "/EHsc", "/nologo", "/Fe:", "${fileDirname}\${fileBasenameNoExtension}.exe", "${file}" ], "options": { "cwd": "${fileDirname}" }, "problemMatcher": [ "$msCompile" ], "group": { "kind": "build", "isDefault": true }, "detail": "compiler: cl.exe" }

[Colengms]

Hi @toninlg . I recommend installing a recent version of Visual Studio instead of "Windows SDK 7.1". It looks like you are trying to use a version of cl.exe included with Visual Studio 2010, which is rather old and no longer supported by the C/C++ extension for VS Code.

I assume you used the build and debug active file feature of the C/C++ extension, to generate your tasks.json. It looks like the /Fe: arg was not supported in that older version of cl.exe. I suspect you could modify your tasks.json by removing the /Fe: and subsequent arg. However, for the best experience, I'd suggest installing a more recent version of Visual Studio, such as Visual Studio 2022 Community Edition.

[toninlg]

Hi. I used "Configure default build task" from terminal to generate tasks.json. On newer compiler :

• /Fe\<file> name executable file
• /Fe: \<file> name executable file are supported but on older one only first option. If I correct this I have linker error on a library not found too. Since our customers can modify themself a part of the code we finally decided to use Visual C++ 2008 Express until now so we don't have to buy VS for the customer and transfer the license to him. If I upgrade to following Express editions, Internet link for registration is dead (I tried 2010). I can request a license for VS2015 Express which is the last Express version but license is requested directly from VS UI so I have no idea how long it would be possible to request a license? I tried to install standalone Visual C++ build tools 2015, it's not detected too.

[Colengms]

Hi @toninlg . We could make a change to use the /Fe<file> syntax whenever generating a tasks.json, to support older compilers.

The tasks.json is used to essentially just issue a command line. If you run the same command line directly, you should get the same result. Can you determine what the correct command line is to successfully compile and link with the compiler you are using? If you could let me know what that is, I could investigate making changes to how the tasks.json is generated, to accommodate.

[toninlg]

Here is the modification I had to do to compile with Windows SDK 7.1 (SDK version is not picked up and not recognized because of the regex but it's the version number given by WindowsSdkVer.exe, so LIBPATH has to be set to find kernel32.lib):

• c_cpp_properties.json

  {
  "configurations": [
      {
          "name": "Win32",
          "includePath": [
              "${workspaceFolder}/**",
              "C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\include"
          ],
          "defines": [
              "_DEBUG",
              "UNICODE",
              "_UNICODE"
          ],
          "cStandard": "c89",
          "cppStandard": "c++98",
          "intelliSenseMode": "windows-msvc-x86",
          "compilerPath": "c:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\bin\\cl.exe",
          "windowsSdkVersion": "7.1.7600.0.30514"
      }
  ],
  "version": 4
  }

• tasks.json

  {
  "version": "2.0.0",
  "tasks": [
      {
          "type": "cppbuild",
          "label": "C/C++: cl.exe build active file",
          "command": "cl.exe",
          "args": [
              "/Zi",
              "/EHsc",
              "/nologo",
              "/Fe${fileDirname}\\${fileBasenameNoExtension}.exe",
              "${file}",
              "/link",
              "/LIBPATH:C:/Program Files/Microsoft SDKs/Windows/v7.1/Lib"
          ],
          "options": {
              "cwd": "${fileDirname}"
          },
          "problemMatcher": [
              "$msCompile"
          ],
          "group": {
              "kind": "build",
              "isDefault": true
          },
          "detail": "compiler: cl.exe"
      }
  ]
  }

• Is there somewhere a list of supported Visual Studio version?

[github-actions[bot]]

Hey @Colengms, this issue might need further attention.

@toninlg, you can help us out by closing this issue if the problem no longer exists, or adding more information.