We have just released VisualGDB 5.2 Preview 3 that comes with out-of-the-box MSBuild support for Embedded and Linux projects (using both remote toolchains and Windows cross-toolchains). It is a lucrative alternative to the GNU Make and CMake build systems that VisualGDB supports as well, so let’s go through the main 10 reasons why it’s worth checking out.

1. Much Faster Builds

The main build system used by VisualGDB before version 5.2  was GNU Make. Although being simple and wide-spread, it is not exactly known for very high performance on Windows. So we designed our MSBuild back-end to spend no processor time on anything except the build. The result is clear: almost twice faster build time. For example, building a typical STM32-based Embedded project on an 8-core system only takes 1.2 seconds.

2. Easy Precompiled Headers

With older VisualGDB and GNU Make you could setup precompiled headers for your project, but that would require complex modifications to the Makefile. The new MSBuild back-end makes precompiled headers easy: add a source file that will create a precompiled header and configure the rest of the files to use them. VisualGDB will take care of the rest.

3. Smart Shared & Static Libraries

In normal Visual Studio projects you can reference a library project to get it linked with your current project. While being convenient, this still requires you to add settings like include directories to each referencing project in order to access the library headers. VisualGDB takes this further by introducing exported settings:Each library can now export a set of include directories (relative to the library project directory), preprocessor definitions, forced includes and extra linker settings. When you reference the library from a project, those settings will be automatically merged with your project settings, saving you the effort of doing it manually.

4. Smart and Precise IntelliSense

If you are building your project on a remote Linux system, VisualGDB will automatically make a list of the include directories it is using and cache them on your Windows machine so that IntelliSense can easily find them. You can see the list of those directories and reload them via VisualGDB Project Properties:

5. Excluded Files and Per-file Settings

If you use MSBuild to build your VisualGDB projects, you can exclude some of your sources from certain configurations and override any compiler settings like optimization for individual files:

6. Resources for Embedded Projects

If you want to embed resources like constant tables, images or voice messages in your embedded projects, the new MSBuild back-end makes it really easy.  Simply add those files to the project, ensure their type is set to “Embedded Binary File” and VisualGDB will automatically convert them into global variables accessible from your code:

7. Quick Up-to-date Check

If you were ever annoyed by the “Project out of date” message shown when you try to debug a VisualGDB project without actually modifying it, we’ve got good news for you. The new MSBuild back-end replaces the normal Visual Studio out-of-date check for VisualGDB projects, so you will never see this message again unless the project is actually out of date:

Note that this only works starting from Visual Studio 2015.

8. Smarter Rebuild

Yet another small annoyance of the GNU Make build system is that adding new files to your project or changing some of the build flags triggers a full rebuild of the entire project. The new VisualGDB MSBuild back-end goes smarter about this and only rebuilds the files when they (or any included headers) are modified or their build command line actually changes. One less thing to worry about.

9. Long Command Line Support

Some embedded SDKs like Nordic nRF51 are notorious for having lots of header files scattered around the SDK, that results in huge command lines when it comes to building your projects. This can quickly fill up the 8191-character command line length limit causing annoying build problems. The new MSBuild back-end takes care of this by using response files instead of command lines, so you will never see this problem again.

10. Building Single Files

Sometimes when you doing massive project changes, you want to build files one-by-one to focus on errors in each file. While not being possible for GNU Make and CMake projects, this is natively supported for MSBuild projects. Simply press Ctrl-F7 and VisualGDB will build the currently open file same way it works for normal Windows projects.

Remote projects

Our new MSBuild back-end also works with projects built remotely over SSH. Before you ask, it doesn’t go crazy about trying to check thousands of remote source files for being out-of-date or try to run numerous commands over a high-latency SSH channel. Instead it simply generates a temporary Makefile, checks if it has changed from the last build, uploads it along with any changed source files and kicks off a remote instance of the good-old GNU Make. All the features like per-file settings and rebuilding only the actually modified files still work transparently.

Downloading

You can download VisualGDB 5.2 Preview 3 with support for MSBuild from the download page (C/C++ MSBuild projects are only supported starting from Visual Studio 2010 and won’t work on VS2008). We’ll be excited to hear your feedback about the new features through our support form or by email. Enjoy VisualGDB.