Support for vcxproj/sln projects

[wmmc88]

Environment

• OS and Version: Windows 11
• VS Code Version: 1.74.0-insider
• C/C++ Extension Version: v1.13.3

I'm trying to use vscode with C++ projects originally created in Visual Studio. These projects are configured via .sln and .vcxproj files. The code navigation is very limited. I cannot "go to definition" or "go to delcaration" when those definitions and declarations are in other files. I believe this is because cpptools doesn't parse vcxproj and sln files in the same way that it parses compile_commands.json databases or other similar files.

Bug Summary and Steps to Reproduce

Bug Summary: "go to definition" or "go to delcaration" does not work when those definitions and declarations are in other files. This occurs in projects based on .vcxproj files

Steps to reproduce:

1. Open a vcxproj/sln based project
2. Click "Go To Declaration"
3. editor doesnt show dclaration

Expected behavior

Ability to fully use all features that rely on cpptools knowing how the project is compiled.

Code sample and Logs

`c_cpp_properties.json`:

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "windowsSdkVersion": "10.0.22621.0",
            "compilerPath": "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe",
            "cStandard": "c17",
            "cppStandard": "c++17",
            "mergeConfigurations": true
        }
    ],
    "version": 4
}

### Screenshots

_No response_

### Additional context

_No response_

[sean-mcmanus]

As of now I don't think we're going to add this. The workaround is to add alternative build files, such as CMakeLists.txt (or somehow generate a compile_commands.json or configure some other way).

[wmmc88]

That's a shame 😕 I'm working with several large projects and it isn't feasible for me to create cmakelists manually for all iof them. I did look into generating a compile_commands json database but for msbuild, there's no 1st party support and I could not find any 3rd party support either.

[github-actions[bot]]

This feature request is being closed due to insufficient upvotes. Please leave a 👍-upvote or 👎-downvote reaction on the issue to help us prioritize it. When enough upvotes are received, this issue will be eligible for our backlog.

[github-actions[bot]]

This feature request has received enough votes to be added to our backlog.

[McPherran]

I politely downvote this idea. VS IDE and VS Code are two different infrastructures - one built on .NET and the other built on Node.js. .NET has classes for working with vcxproj files as part of the infrastructure. Each environment has its strengths. If one likes vcxproj, VS IDE is available, if one likes json files or CMake, then VS Code is a great option. If one already has vcxproj, then one may use VS while transitioning to VS Code. One could even edit the vcxproj file as text to cut and paste the source files list to CMake or json sources list, for a quick start to create these.

Documentation for converting to CMake: https://cmake.org/cmake/help/book/mastering-cmake/chapter/Converting%20Existing%20Systems%20To%20CMake.html

Even a tool to help convert vcxproj to CMake is available: https://github.com/mrpi/proj2cmake/tree/master/src

The VS C++ Build Tools license now fully supports VS IDE or VS Code: https://visualstudio.microsoft.com/license-terms/vs2022-ga-diagnosticbuildtools/ https://github.com/microsoft/vscode/issues/208518#issuecomment-2916940198

I very much like VSCode, but I have vcxproj files and I'm happy to stay with the VS IDE. It's a simple matter of preference, based on the particular advantages of each.

[bersbersbers]

I politely downvote this idea.

I am not sure from which perspective you are writing but let me politely disagree with your opinion from a user perspective.

VS IDE and VS Code are two different infrastructures - one built on .NET and the other built on Node.js. .NET has classes for working with vcxproj files as part of the infrastructure.

As a user, I could not care less. Just because a feature is harder to implement here than there does not make me want it less.

If one likes vcxproj, VS IDE is available, if one likes json files or CMake, then VS Code is a great option.

I do not like vcxproj, and yet I have to use them, which is why ...

If one already has vcxproj, then one may use VS while transitioning to VS Code

... this is nonsense. "use VS while transitioning to VS Code" means "use VS forever" if VS Code does not understand vcxproj files.

One could even edit the vcxproj file as text to cut and paste the source files list to CMake or json sources list, for a quick start to create these.

Sure. And this one repeats every time the vcxproj in source control changes?

Even a tool to help convert vcxproj to CMake is available:

I may be doing that tool injustice, but sorry, I am not even going to clone a repository that been unmaintained for 7 years. (I have unsuccessfully tried a similar tool before.)

I'm happy to stay with the VS IDE.

Your preference be granted. I do wonder why you are posting it in the repository of an extension of a different IDE, though. This is vscode-cpptools after all.

[McPherran]

Dear @bersbersbers,

I do not like vcxproj, and yet I have to use them, which is why ...

If that is a business/management decision, that's a separate issue, but if that issue can be solved, it solves the problem.

Your preference be granted. I do wonder why you are posting it in the repository of an extension of a different IDE, though. This is vscode-cpptools after all.

I probably arrived here from a web search, I don't recall specifically. However, I have been researching and seeking to ascertain whether the general trend is towards VSCode deprecating the VS IDE altogether. I would welcome that, as I am on the teetering edge of switching to VSCode. One obstacle had been the Build Tools License which is apparently no longer an issue.

In fact, I had already asked this two days ago, before I posted here: https://github.com/microsoft/vscode-discussions/discussions/2714