getcursor
Configured debug type 'cppvsdbg' is installed by not supported in this environment
- If you can, please include a screenshot of your problem
- Please include the name of your operating system
- If you can, steps to reproduce are super helpful
Operating System: Windows 10
- Create a CPP project using the run & debug feature of VSCode via the tasks.json/launch.json files
- Try to run & debug a project with 'cppvsdbg' as the type
The above works fine in my VSCode but it would be really nice if I could also use this feature in Cursor and to my knowledge I don't believe the issue to be on my side.
On Windows 10 here and getting the same issue. I heard somewhere that this may be due to Microsoft limiting some stuff behind their official VSCode builds. Not sure if that is the case here, but I thought I should at least comment. Please let me know if I am wrong.
Me too
I am having the same problem.
I am on Windows 11
Now on August 8, 2024, the latest version of cursor hasn't solved this problem. Do you guys have any other solutions?
I'm getting this too. That's too bad because this is a show-stopper for me.
This is the version of Cursor I'm using:
This is the version of VSCode (which works) that I'm using:
This is kind of too bad. I love what I've seen the last week with Cursor.
But if Cursor breaks on something like an extension setting like this, it means Cursor is probably implemented in a fairly fragile kind of way and can probably be expected to break a lot on non-standard environments and non-standard workflows.
Visual studio c++ on Windows is already pretty non-standard in the whole software development milieu, and msvc within VS Code is even more non-standard. I'm wondering if this development path, using Cursor.ai, will ever really work. This is a completely show-stopping bug that has been around for literally a year now and it doesn't seem to be any closer to being fixed.
Working with a new dev tool is an investment. You have to spend time and mental energy setting up a comfortable and productive environment, and if Cursor is just going to break every once in a while, I'm not sure it's really worth getting to know - not only for C++ but for python and typescript and my other dev environments. The one saving grace here is if Cursor was working and it broke again, I could probably just uninstall it and revert to using VC code + copilot.
Anyhoo, we'd really appreciate a fix, here.
same issure here:
Version: 0.39.6 VSCode Version: 1.91.1 Commit: a4f99b7dfb14460cb0bcebd9f6ac7ca158217920 Date: 2024-08-19T00:03:08.275Z Electron: 29.4.0 ElectronBuildId: undefined Chromium: 122.0.6261.156 Node.js: 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.19045
That's too bad. Bought the subscription yesterday and already faced with a showstopper.
I'd like to ask what the official stance is on this issue. I don't know if this will be addressed officially in the future, or a way to bypass it will be provided.
I was thinking of moving to cursor for my C++ apps, and hit with this showstopper too
I figured out the solution. Now I can run UE5 with cursor.
The problem is caused by cppvsdbg, as well as vsdbg, which is exclusively licensed by Microsoft product.
To solve this, you need to set up your debugger. I use GCC with MinGW.
How exactly should I set up the debugger, I have installed g++,gcc, etc debug
Should I select launch VsCodeCursorEditor(Development)(workspace) for debugging
I figured out the solution. Now I can run UE5 with cursor.
The problem is caused by cppvsdbg, as well as vsdbg, which is exclusively licensed by Microsoft product.
To solve this, you need to set up your debugger. I use GCC with MinGW.
That's very frustrating, and for many users just switching to gcc isn't really an option.
But I guess we have our answer.
sad,I am hesitating whether to switch from GitHub+vs to this, I use UE5 .
I figured out the solution. Now I can run UE5 with cursor.
The problem is caused by cppvsdbg, as well as vsdbg, which is exclusively licensed by Microsoft product.
To solve this, you need to set up your debugger. I use GCC with MinGW.
Thank you for your method, but I think MSVC is the best way to debug UE5, and it seems that it doesn't complete much of the program I wrote myself. I wonder if this is the case when you developed with UE5
It really is a shame. I ran into the same issue too. Unfortunately, this is out of Cursor's control. These build tools are proprietary and Microsoft doesn't allow them to be used outside of the official builds of VS Code. Fortunately, I personally was able to just install GCC and was able to compile my program and run successfully. If you can, use GCC. If you can't, you're just going to have to use Cursor to write code, then use Visual Studio or the official VS Code client to build and debug.
https://github.com/microsoft/vscode-cpptools/issues/4707#issuecomment-562670907
Yeah I think this is a deeper issue. May just have to use vanilla vscode if you want to use cppvsdbg for c++ projects for now
Facing the same problem. The extension has been installed. Environment variables are set.
Facing the same problem. The extension has been installed. Environment variables are set.
Open the Command Pallet (Ctrl+Shift+P), and set the C++ compiler to use GCC. That should do the trick far as C/C++ goes.
Open the Command Pallet (Ctrl+Shift+P), and set the C++ compiler to use GCC. That should do the trick far as C/C++ goes.
To elaborate on this, here are the specific steps required to setup Cursor for building C++ projects (I only tested this with Unreal Engine 5 uprojects. I'm not building the engine from source, so no clue if gcc will work for that):
1. Create Unreal Engine C++ project in editor normally.
2. Download and install latest MSYS2 (https://www.msys2.org/)
3. Open MSYS2 and install the MinGW-w64 toolchain:
pacman -S --needed base-devel mingw-w64-ucrt-x86_64-toolchain
4. Add the compiler dir to your User PATH:
- Search Windows for "Edit Environment Variables For Your Account"
- Edit
Path, addC:\msys64\ucrt64\binto the list. - Click Ok then Ok again to close Environment Variables window (this must be done to actually apply changes. If you add it to System Path, then reboot is required!)
5. Open New Cmd or Powershell window and ensure all packages installed correctly:
gcc --version
g++ --version
gdb --version
6. In Unreal Engine, Open Editor Settings > General > Source Code and set default IDE to Visual Studio Code. Close Editor Settings.
7. Go to Tools menu and click Generate/Update Visual Studio Code Project Files (this will create the .code-workspace file in your project root
8. Open <YourProjectName>.code-workspace in Cursor
9. Ctrl+Shift+P to open Command Pallet and select C/C++: Edit Configurations (UI) then select <YourProjectName>
10. Edit the following variables:
-
Configuration Name: Set to the correct config generated by Unreal (for most people this is<YourProjectName>Editor Editor Win64 Development (<YourProjectName>) -
Compiler Path: You should now seeC:\msys64\ucrt64\bin\gcc.exein the dropdown, select that -
IntelliSense Mode: Set it to match your compiler, in this casewindows-gcc-x64 -
Include Path: Add the following recommended entries, each on a new line (you can add more depending on your needs):
${workspaceFolder}\Intermediate\**
${workspaceFolder}\Plugins\**
${workspaceFolder}\Source\**
-
Defines: Add the following entries, each on it's own line:
UNICODE
_UNICODE
__UNREAL__
UBT_COMPILED_PLATFORM=Windows
WITH_ENGINE=1
WITH_UNREAL_DEVELOPER_TOOLS=1
WITH_APPLICATION_CORE=1
WITH_COREUOBJECT=1
11. Open the Command Pallet (Ctrl+Shift+P) and type/open launch.json
12. Scroll down to "launch": {, and under "configurations": [ find all references to "type": "cppvsdbg" and change those to "type": "cppdbg" (this is required because the "cppvsdbg not supported in this evironment" error will still show if any of the Launch Configurations are set to cppvsdbg
13. That's it! If you're starting with Unreal Engine from scratch (never setup VS Code for compiling UE5 projects before), or something is funky with IntelliSense, then reference this page for more info: Setting Up VS Code for Unreal Engine
Let me know if I missed anything and I'll update the steps above!
I blundered into trying this MinGW-w64 GDB compiler solution, not realising what was going on. Yes it works and will run in debug mode but it is EXTREMELY SLOW to the point that it's just not worth bothering with, at least for my project.
As far as I can tell Cursor just doesn't work for debugging C++ in windows. I understand why they dont want to draw attention to this (it casts a shadow over the project's long term viability in the shadow of MS) but it means that people like us are continually having our time wasted, trying to set up our projects to work with Cursor when it's just not doable.
launch.json
"configurations": [
{
"name": "demo",
"type": "lldb",
"request": "launch",
"program": "${command:cmake.launchTargetPath}",
"args": [],
"stopAtEntry": false,
"cwd": "${command:cmake.launchTargetDirectory}",
"environment": [],
"internalConsoleOptions": "neverOpen",
}
]
change cppvsdbg to lldb in type.
While changing to lldb could be a solution, but it needs extra steps to make it work and every new project I start I have to redo some of these steps again:
- Python version should match the version used in llvm. (multiple versions might exist in your PC, how lldb chooses one is still not clear for me)
- CodeLLDB extension doesn't work sometimes (the solution proposed in above command) and is not official, LLDB-dap is the official one and that also doesn't work sometimes
- std types are not correctly shown in debug (such as std::vector> adding special formatters are needed for those types.
- it is pretty slow compared to cppvsdebug.
Although I think using lldb is the final solution, but would be nice for cursor to spend sometime to provide a wrapper around this extension to make it usable and support it to make it bug free. For example CLion does the same.
Another issue is that using LLDB for debugging is significantly slow, especially for large projects. That's also why I haven't switched to LLDB.
Another issue is that using LLDB for debugging is significantly slow, especially for large projects. That's also why I haven't switched to LLDB.
"Significantly slow" is putting it politely. It's not a solution for big projects imo, Cursor is off the table.
Another viable workaround: keep normal VSCode running in the background, and switch to it for debugging. None of cursor's AI features interact with the debugger, that I know of... so you're not missing out on anything.
