Forum Replies Created
-
Posts
-
Hi,
This looks like a bug in some of the tools used to program the FLASH memory. If you are using OpenOCD, you can try installing earlier package versions via Tools->VisualGDB->VisualGDB Package Manager. If you are using a different tool, you can try running it manually on different machines to see if there is any pattern.
Hi,
We have just retested it with ESP-IDF 5.5.1, and it worked mostly fine. The default project template had the MINIMAL_BUILD property turned on, that would prevent the new component from being built, but disabling it fixed it just fine.
We have updated our tutorial accordingly.
Hi,
Well, googling up “.Net path length limitation” is not the real problem here. The problem is side effects in a system where we don’t control every part.
VisualGDB is an extension that gets loaded into at least 3 different .Net processes: Visual Studio GUI itself, background MSBuild worker, and MSTest runner. Globally changing the manifest for even one of them is almost guaranteed to trigger some unexpected behavior in some other plugin that is loaded into the same application.
So, what we do when it comes to workarounds, is look whether the fix is reducing or increasing the external complexity. Changing a global manifest (so every single MS assembly inside devenv will run under different global configuration than it was ever tested by MS) would be a huge no. Manually copying files under long paths might blow back if another extension (or VS component) tries to enumerate them, and doesn’t handle the paths accordingly. It’s tolerable if we were fixing a major bug (e.g. debugging completely broken for multiple projects), but not worth it for a cosmetic fix.
What we ended up doing (removing the extra copying step) actually reduced the external complexity (each project has now fewer files), so we wouldn’t expect it to break anything else that wasn’t broken already.
Hope this explains.
Hi,
It’s a good question what to consider a band-aid in this case. All VisualGDB does is copies the files created by CMake under a slightly longer path using the standard .Net copying API. One could argue that a proper fix would be to understand why the .Net framework doesn’t handle this properly, since many other tools, including Visual Studio itself, also heavily use .Net.
Either way, we have recently updated our CMake subsystem to support toolchains coming from vendor-specific VS Code extensions, and were also able to optimize away the extra copying of response files. Feel free to try this build: VisualGDB-6.1.3.5439.msi
OK, we are not really sure how you managed to get the gnu2b value in the first place (searching ESP-IDF for gnu2b doesn’t find anything, and googling it only finds your post). We would advise double-triple-checking everything to avoid breaking things further.
That said, as promised, we have updated our Clang IntelliSense engine to the latest Clang 21.1. So, it should work with the latest language standards supported by Clang. You can try the new version here:
Update: the issue could have been related to the old mapping rule that would replace the gnu++23 standard with gnu++2b (as needed by Clang 16.0). Applying that rule to gnu23 would have yielded an invalid value of gnu2b, but then the CMake fix you mentioned would not work because CMake would be outputting gnu23 and the gnu2b would be substituted later.
Either way, the new engine based on Clang 21.1 does not use this mapping, and should work just fine.
Hi,
This is tricky. This particular error happens when VisualGDB tries to copy the CMake code model to its own cache directory. The original file path is likely just below the MAX_PATH limit, and the one in the VisualGDB’s cache directory is above.
The good fix for this would be to try convincing the CMake maintainers to put a length limit on the code model file names, so the problem wouldn’t happen in the first place.
Another option would be to enable the legacy server mode instead of the file mode via Tools->Options->VisualGDB->CMake->API for querying CMake state.
We will take another look at the VisualGDB’s logic for reading the model files in about a week, and will see if we can add a better workaround.
Hi All,
We got VS2026 integration working reasonably well. There are still more tests to run, but this version [VisualGDB-6.1.2.5416.msi] will work much better than the copied Extensions folder.
Hi,
No problem, you can try this tutorial: https://visualgdb.com/tutorials/linux/
Hi,
Thanks for pointing this out! We will look into updating the Clang version used by VisualGDB, so that it handles the gnu2b natively. Until then, gnu17, or gnu2x should work.
Hi,
Last time we checked, it could be safely ignored. If you install the same packages with Arduino IDE, it just silently skipped these long paths, and everything still got built just fine. So, we just replicated its behavior, but added a warning just in case.
We would advise against registry hacks, as it could have some weird side effects (e.g. cause some internal errors in gcc). You can also try convincing Espressif to update their package structure, as it might eventually start causing problems for Windows users.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Hi,
We are still working on official integration (should be ready in a couple of weeks). If you don’t want to wait, you can try copying the VisualGDB’s folder from VS2022’s Extensions folder to the VS2026 Extensions folder, and enabling VisualGDB in the VS Extensions menu, but it may not work (we haven’t tested it).
Once we officially support it, it will work out-of-the-box.
Hi,
Thanks for renewing your support.
This behavior is somewhat expected with the GNU Make projects. The regular Make project subsystem expects a particular Makefile layout, that places a few constraints on the project structure. One is that the build command should always run from the Makefile’s directory. The other one is that CFLAGS and other settings should be specified in a very rigid way, so VisualGDB can edit them using relatively simple regular expressions. You get the general idea by creating a new Make project, changing a few things via the GUI, and checking what files got changed as a result.
If you have an existing big project with non-trivial Makefiles, we would advise importing it as an externally built project. It will remove all constraints on the command line, but things like include directories would require manually updating the Makefiles.
A better (but more time-consuming option) would be upgrading to CMake. Unlike Make, CMake can produce machine-readable information about the project structure, so unless you do something really tricky (like custom macros), you can just select a target in Solution Explorer, change its properties, and VisualGDB will automatically find and edit the correct CMakeLists file defining that target.
OK, good news for all ESP32 users. We have looked into the tool structure used by the Espressif’s VS Code extension, and they look very solid and well-organized.
So, we updated VisualGDB to directly use exactly the same packages that the VS Code extension does, and hence produce exactly the same results. You no longer need to wait for an updated toolchain from us; any IDF/ADF version from Espressif that works with VS Code now also works with VisualGDB out-of-the-box, producing exactly the same results.
You would need to update to the latest VisualGDB 6.1 Beta 1 in order to use the new setup.
We also published a detailed documentation page on the new project structure here: https://visualgdb.com/documentation/espidf/consolidated/
