Today we are proud to announce the release of VisualGDB 5.4R3. This is a maintenance release that focuses on gradually improving the VisualGDB experience across many supported project types and scenarios and in this post I will give you an overview of this version’s highlights.
Visual Studio 2019 Support
Starting from this version, VisualGDB officially supports Visual Studio 2019. We have rigorously tested it with a variety of configurations and project types and ensured that it will deliver the usual VisualGDB experience just as with the other VS versions:We have also updated our installer to handle multiple installations of the same VS version, so having both Visual Studio Community and Enterprise installed won’t confuse it anymore. The default install will now integrate into every discovered VS version and the custom install will let you choose the specific installations:
One of the bottlenecks of the previous VisualGDB versions was the necessity to load VisualGDB during Visual Studio’s startup. This was needed to handle the projects based on the regular Visual C++ project format, but would delay Visual Studio initialization by a few seconds. In VisualGDB 5.4R3 this is no longer the case – the only part initialized at startup is a very lightweight loader that will quickly scan each loaded VC++ project file for VisualGDB markers. The rest will be loaded first time you use a VisualGDB wizard, menu command, or open a project containing VisualGDB configurations.
New High-efficiency BSP Format
If you are using VisualGDB to target embedded devices, you normally don’t need to download any SDKs yourself – just pick the device from the list and VisualGDB will get the necessary files for you. As the amount of supported devices and included libraries kept steadily growing over the past years, so did the download sizes. So in VisualGDB 5.4R3 we decided to optimize this process to the limit to ensure you get board and device support files as fast as possible. First of all, we are introducing a new BSP format based on the high-efficiency LZMA compression, that typically reduces the download size by 4-6x. E.g. the latest STM32 BSP is now just 38MB instead of 214MB (don’t worry, we will ship both versions of BSPs for the next few years for backward compatibility). Secondly, all VisualGDB downloads are now served by separate content delivery servers, making the downloads dramatically faster.
ESP-ADF and ESP8266 RTOS SDK 3.0 Support
We have extended our ESP-IDF project wizard to support ESP-ADF (Audio Development Framework) and the ESP8266 SDK 3.0 that is based on the ESP-IDF build scripts. As long as you are using the latest toolchains, simply select the correct SDK in the wizard and VisualGDB will take care of the rest:
Better IntelliSense for Header Files
We have designed the Advanced Clang IntelliSense to be extremely precise – it queries the exact settings for each file directly from the underlying project subsystem. This works great for C/C++ source files, however has one catch: if you add a new header file to the project and do not include it from any source files, VisualGDB won’t know the exact build settings (e.g. preprocessor macros) for that file. It would normally guess them based on the settings for the nearby source files, however this process is not 100% accurate and sometimes leads to confusing results.
To make sure this won’t impact your productivity, VisualGDB will now show an explicit warning when it guesses the arguments for a header file. So simply include it from a regular source file, hit “refresh” and you’ll get a rock solid IntelliSense again: